home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
BBS Toolkit
/
BBS Toolkit.iso
/
rbbs_pc
/
172bdoc.zip
/
RBBSDOC1.ASC
< prev
next >
Wrap
Text File
|
1989-05-27
|
389KB
|
6,836 lines
REMOTE BULLETIN BOARD SYSTEM
for the
IBM Personal Computer
Version CPC17.2A
Technical Reference Guide
Technical Support Number
(203) 268-9656
(calls returned COLLECT)
Copyright 1983-1989
by
D. Thomas Mack
39 Cranbury Drive
Trumbull, Conneticut 06611
DATA #1 -- (203) 268-5315
#2 -- (203) 268-0129
Jon Martin
4396 N. Prairie Willow Ct.
Concord, California 94521
DATA -- (415) 689-2090
Ken Goosens
5020 Portsmouth Road
Fairfax, Virginia 22032
DATA #1,2,3 -- (703) 978-6360
May 28, 1989
RBBS-PC CPC17-2A Page 2
TABLE OF CONTENTS Page Updated
----------------- ----
1. INTRODUCTION 6
1.1 The Capital PC Users Group 6
1.2 The "contributions" requested for RBBS-PC 7
1.3 The "history" behind RBBS-PC 8
1.4 RBBS-PC Update Conventions 16
1.5 Beta test sites, Where and Why 18
1.6 An Example of "Users Helping Users" 20
2. SUMMARY OF RBBS-PC'S FEATURES 22
2.1 General 23
2.2 Messaging 24
2.3 File System Management and Exchange 26
2.4 The User Interface 28
2.5 SYSOP Protection 30
2.6 SYSOP Functions, Features, and Support 31
2.7 System Access Management 33
2.8 Communications 34
2.9 "Base-Line" Hardware and Software Requirements 36
3. RBBS-PC's SUPPORT POLICIES 38
3.1 RBBS-PC's Vendor Support Policy 38
3.2 RBBS-PC's User Support Policy 42
4. HOW TO GET A COPY OF RBBS-PC SENT TO YOU 43
5. FILES RBBS-PC USES 44
5.1 RBBS-PC System Files 45
5.2 RBBS-PC Text Files 48
6. INSTALLING RBBS-PC FOR THE FIRST TIME 51
7. COMMON PROBLEMS ENCOUNTERED INSTALLING RBBS-PC 56
8. PLANNING YOUR USER INTERFACE 58
8.1 Menus Shown to Callers 58
8.2 Subsystem Prompts Shown to Callers 59
8.3 Commands Available to Callers 60
8.4 RBBS-PC's "Wrap-around" Command Search 61
8.5 How to Have a Single Universal Command Line 62
8.6 RBBS-PC'S Programmable User Interface (PUI) 65
8.6.1 An Example Using PUI 66
8.6.2 How to Implement PUI 67
8.7 RBBS-PC's Support of Sub-menus 70
8.7.1 How to Implement Sub-menus 72
*8.7.2 Shared Options Across Sub-menus 72
8.8 RBBS-PC's "Macro" Command Support 73
8.8.1 How To Set Up "Macros" 75
*8.8.2 Macro Commands 76
8.8.3 A Sample Macro 81
*8.8.4 On-line Data Base With Macros & Questionnaires 82
8.9 RBBS-PC's "Smart" Text Files 86
8.10 "Colorizing" the RBBS-PC User Interface 88
* New or substantially revised.
RBBS-PC CPC17-2A Page 3
TABLE OF CONTENTS Page Updated
----------------- ----
8.11 RBBS-PC's Automatic Operator Page Option 91
*8.12 Enhancing the File Verbose List 93
9. UNIQUELY IDENTIFYING YOUR CALLERS 95
9.1 Setting Up Identifying and Individuation Fields 96
9.2 Preloading Identities For Instant Access 97
10. RBBS-PC's AUTOMATIC SUBSCRIPTION/ TIME MANAGEMENT 99
10.1 Setting It Up 100
11. USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC 100
11.1 Global RBBS-PC Parameters (Part 1 of 3) 101
11.2 Global RBBS-PC Parameters (Part 2 of 3) 103
11.3 Global RBBS-PC Parameters (Part 3 of 3) 105
11.4 Parameters for RBBS-PC System Files (part 1) 108
11.5 Parameters for RBBS-PC System Files (part 2) 111
11.6 Parameters for RBBS-PC "Doors" 114
11.7 Parameters for RBBS-PC's Security (part 1) 117
11.8 Parameters for RBBS-PC's Security (part 2) 119
11.9 Parameters for Multiple RBBS-PC's/Conferences 123
11.10 RBBS-PC SYSOP Utilities 126
11.11 RBBS-PC's File Management System Parameters 128
11.12 Communications Parameters (part 1) 132
11.13 Communications Parameters (part 2) 136
11.14 Parameters for RBBS-PC NET-MAIL 137
11.15 New Users Parameters 139
11.16 Use of the Library Sub-System 140
11.17 RBBS-PC's Parameters for Color 142
12. THE HAYES MODEM SWITCH SETTING AND CONSIDERATIONS 143
12.1 Hayes Smartmodem 1200 Switch Settings 143
12.2 Hayes Command's Considerations 145
12.2.1 Command to Reset the Modem 145
12.2.2 Command to Initialize the Modem 145
12.2.3 Command to Count The Number of Rings 145
12.2.4 Command to Answer the Phone 146
12.2.5 Command to Take the Phone Off the Hook 147
12.2.6 Smartmodem 2400 Firmware Initialization 147
12.2.7 Smartmodem 9600 Firmware Initialization 149
13. RBBS-PC's FILE MANAGEMENT SUBSYSTEM 151
13.1 Multiple Directory Format 152
*13.2 The Single and Chained FMS Directory Format 154
13.3 Advantages/Disadvantages of FMS Directory 155
13.4 Creating FMS Directories 158
13.5 Defining the FMS Category Codes 160
13.6 The "Library" Subsystem, CD-ROM, and FMS 161
13.6.1 How the "Library" Subsystem Works 163
13.6.2 The "Library" Subsystem and PC-SIG's CD-RO 164
13.7 Creating the Personal Files Directory 165
*13.8 Automatically Checking & Converting Uploaded Files 169
* New or substantially revised
RBBS-PC CPC17-2A Page 4
TABLE OF CONTENTS Page Updated
----------------- ----
14. SETTING UP ".BAT" FILES FOR RBBS-PC 171
15. THE USE OF RBBS-PC "DOORS" 172
15.1 "DOORS" Are Nothing More Than .BAT Files 172
15.2 A Sample .BAT File for a "DOOR" 173
15.2.1 Redirect I/O Using the CTTY Method 173
15.2.2 Redirect I/O Using the CTTY Method 173
15.3 Setting Up and Testing a "DOOR" 174
*15.4 Invoking "DOOR"s Via The External Control File 176
15.5 EXITing or SHELLing to "DOOR"s 177
15.6 Reseting The User's Record Via a "DOOR" 178
15.7 A Summary of "DOOR"s 178
16. THE SECURITY FEATURES OF RBBS-PC 180
16.1 RBBS-PC's Security Features 181
16.2 Examples of Uses for RBBS-PC's Security System 182
16.3 How to Implement the Password File 184
16.4 Implementing Security for Download Files 187
16.5 Implementing Security for RBBS-PC Commands 189
16.6 Beware of the "Trojan Horse!" 191
17. SYSOP FUNCTIONS 192
17.1 SYSOP Commands Within RBBS-PC 192
17.2 SYSOP Use of Function Keys and Numeric Pad 194
18. MESSAGE AREAS WITHIN RBBS-PC 196
18.1 "Conferences" and "Sub-boards" -- the Differences 196
18.2 Making a "Conference" or "Sub-board" Successful 199
18.3 Setting Up a "Conference" or "Sub-board" 200
*18.4 Establishing a "Conference" or "Sub-board" SYSOP 201
19. CALLERS AUTOMATIC NOTIFICATION OF MAIL WAITING 202
20. RBBS-PC QUESTIONNAIRE FACILITIES 204
*20.1 Branching to Labels 205
*20.2 Display Data Command 206
*20.3 Display Data And Get Response 206
20.4 Multiple Choice Responses 207
20.5 Forward and Backward Branching 207
20.6 Raise/Lower User's Security Level 207
20.7 Abort Questionnaire 208
20.8 Chain Questionnaire 208
*20.9 Turbo Key 208
*20.10 Macro Execute 208
*20.11 Assign Value 209
21. RBBS-PC's STANDARD INTERFACE FOR PROTOCOL DRIVERS 210
21.1 Parameters passed to a protocol driver 211
21.2 Calling external protocols using "templates" 215
21.3 Parameters Returned by a Protocol Driver 217
21.4 The Protocol Drivers Tested With RBBS-PC 218
* New or substantially revised
RBBS-PC CPC17-2A Page 5
TABLE OF CONTENTS Page Updated
----------------- ----
22. UPLOADED FILE TIPS 219
23. DUE WARNING AND SYSOP'S LEGAL LIABILITY 221
24. COMPILING AND LINKING RBBS-PC 222
24.1 Compiling CONFIG and RBBS-PC 222
24.2 LINKing CONFIG 223
24.3 LINKing RBBS-PC 223
25. LIMITED LICENSE 225
26. LIMITED WARRANTY 226
27*. UPGRADING TO CPC17-2A 227
28. PROPOSED AGENDA FOR A NATIONAL SYSOP CONFERENCE 229
29. RBBS-PC, THE LARGEST SOFTWARE HOUSE IN THE WORLD 231
APPENDIX A -- RBBS-PC Record Formats 232
APPENDIX B -- RBBS-PC in a DESQview Environment 238
APPENDIX C -- RBBS-PC in a MultiLink Environment 242
APPENDIX D -- RBBS-PC in a CORVUS Network 244
APPENDIX E -- RBBS-PC in ORCHID or AST PCnet NETWORK 245
APPENDIX F -- RBBS-PC in an Alloy PC-SLAVE/16 Environment 247
APPENDIX G -- RBBS-PC and 10 NET Network 252
APPENDIX H -- RBBS-PC and the Hearing-Impaired 253
APPENDIX I -- RBBS-PC and the IBM PCjr 254
APPENDIX J -- RBBS-PC Subscription Service 256
APPENDIX K -- RBBS-PC National Listing Service 257
APPENDIX L -- The Ark-Paradyne Modem RBBS-PC Switch Settings 258
APPENDIX M -- RBBS-PC And the Anchor Signalman Express (MK12) 261
APPENDIX N -- The Everex 2400 modem RBBS-PC switch settings 262
APPENDIX O -- Prometheus 2400G modem RBBS-PC switch settings 263
APPENDIX P -- US Robotics Modems' RBBS-PC Switch Settings 264
APPENDIX Q -- RBBS-PC and the FASTCOMM 2496 Turbo Modem 266
APPENDIX R -- RBBS-PC and the ZOOM Modem HC2400 268
APPENDIX S -- RBBS-PC And The AT's RS-232 Cable 269
APPENDIX T*-- RBBS-PC And BASIC Compiler Patches for "Doors" 270
APPENDIX U*-- Using RBBS-PC to access ORACLE or dBASE Remotely 277
APPENDIX V -- Using RBBS-PC with SEAdog to Access FIDO-NET 281
APPENDIX W -- DOS Limitation on Running Programs Remotely 285
APPENDIX X -- Using RBBS-PC with DoubleDOS 286
APPENDIX Y -- Recompiling RBBS-PC to Reduce Memory Required 288
APPENDIX Z -- The MICROCOM AX9624c RBBS-PC Switch Settings 290
APPENDIX AA-- The Leading Edge Series L 2400B Modem 291
* New or substantially revised.
RBBS-PC CPC17-2A Page 6
1. INTRODUCTION
---------------
RBBS-PC is a Remote Bulletin Board System for the IBM personal computer,
hence the name RBBS-PC. RBBS-PC has two fundamental purposes --
A. to be a catalyst for the free exchange of information, and
B. to serve as an educational example of what can be done with BASIC.
RBBS-PC is distributed under the trademark "Userware" because RBBS-PC
is the sure and present proof that software which is shared becomes
better than it was. RBBS-PC is the result of many thousands of man-
hours of effort and is what it is today because of the many software
contributions and suggestions by members of the Capital PC Users Group
and others. Everyone has something that they believe strongly in. For
me it is the "Userware" concept and the free exchange of information.
As John Naisbitt states in his book, MEGATRENDS,
"...the new source of power is not money in the hands of a few, but
information in the hands of the many."
For this reason I have devoted the time I have in writing, maintaining,
and enhancing RBBS-PC over the years. The reason that I am the
registered copyright owner of RBBS-PC and grant the limited license that
I do is to primarily insure that these purposes are not abrogated.
1.1 The Capital PC Users Group
------------------------------
Because the fundamental purposes of RBBS-PC and the Capital PC User Group
are similar, each new version of RBBS-PC is initially sent to the
CPCUG's Software Exchange for distribution. CPCUG is a Maryland
Corporation whose "legal name" is the Capital PC User Group Inc. The
CPCUG is an all-volunteer, non-profit organization according to Section
501C3, Social Welfare, of federal law. All revenues are re-invested
in and applied toward CPCUG's education programs.
RBBS-PC CPC17-2A Page 7
1.2 The "contributions" requested for RBBS-PC
----------------------------------------------
The "contributions" requested for RBBS-PC can be one of four types:
A. Modifications to RBBS-PC, itself, that are documented and distributed
as .MRG files against the "base-line" source code that other SYSOPs might
elect to incorporate into their version of RBBS- PC (remember RBBS-PC can
not be distributed in modified form with violating both the RBBS-PC
copyrights and the limited license granted with it's use).
B. Publicly distributable software. It can either be "public domain"
(i.e. software which the author has relinquished all rights and which may
be appropriated by anyone for use in any way), or publicly distributable
software (i.e. software in which the author has retained his rights and
which may only be used according to the conditions under which the author
has designated).
C. Equipment or services. Be inventive in light of the CPCUG's
objectives under 1.1. If you or your organization can donate equipment,
software, supplies, or services to the CPCUG, feel free to do so. If
you are so inclined, but before you do so, contact the Capital PC User
Group, 51 Monroe Street, Plaza East Two, Rockville, MD 20850. For general
information about the appropriateness of the bequest, contact the
Capital PC User Group directly at (301) 762-6775.
D. Money - the last level of "contribution". Money is the one commodity
that we are willing to exchange among each other without first having
obtained the respect, consideration, etc. of the other party. It is
perhaps the easiest to give as it exonerates us from the other levels
of "contribution." CPCUG is an all volunteer organization and, of
course, money is seldom plentiful. However the essence of CPCUG is
the time, ideas, and effort that each of the volunteers contribute to
it. For this reason, while money is always appreciated, money is not
the best or even the second-best type of "contribution" you could
make.
Independent of any donations of enhancements to RBBS-PC, publicly
distributable software, equipment, services, supplies, or money,
consider becoming a member of CPCUG. Simply send your name, address, and
phone number along with $35 to CPCUG, 51 Monroe Street, Plaza East Two,
Rockville, MD 20850 or call their membership hot line at (301) 670-1737.
If in the final analysis you feel that you can do none of the above,
o remember those who have,
o enjoy what they have nurtured, and
o keep the faith with those who have gone before you.
RBBS-PC CPC17-2A Page 8
1.3 The "history" behind RBBS-PC
--------------------------------
Electronic bulletin board systems have been around ever since personal
computers existed. The first ones were very primitive and usually
consisted of some posted notices and maybe allowed for on-line messages.
It must be remembered that the IBM PC was only announced in August of 1981
and first became available in October of 1981. Therefore it is not
surprising that the early history of BBS' is associated with non-IBM
personal computers.
The "early history" of bulletin board systems began around 1978 in Chicago
with the CBBS/Chicago (Computerized Bulletin Board System/Chicago). It was
created by Ward Christensen and Randy Suess -- members of the Chicago Area
Computer Hobbyist Exchange (CACHE). CBBS for the CP/M is written in 8080
Assembler language (11,000 lines of it) and, like the early versions of
RBBS-PC (i.e. prior to CPC12-5A), detects the baud rate and the parity of
the user when he first signs on from the three carriage returns that the
user must enter.
About the same time, Bill Abney wrote a BBS for the Radio Shack TRS-80
Models I and II called Forum-80.
The earliest BBS that I know of was written for the Apple (who else had
personal computers in those days?) called the "Apple Bulletin Board System"
(ABBS). It was written by Craig Vaughn and Bill Blue. They later created
another bulletin board system for the Apple II called the People's Message
System (PMS).
Another Apple bulletin board system that came into being was for the Apple
II, II+, and IIE as well as the Franklin Ace and it was called the
CommuniTree. It was written in the FORTH language by Dean Gengle and
several others.
When IBM announced its first personal computer, the IBM PC, in August of
1981, there was no BBS for it. In the summer of 1982, Brad Hanson found a
prototype version written by Russ Lane in IBM's BASIC on David Crane's
Dallas RCP/M\CBBS system. Brad added many fixes and modifications. In the
first half of 1983, many members of the Capital PC Users Group's
Communication Special Interest Group (SIG) such as Larry Jordan, Rich
Schinnell, Gary Horwith, Jim Fry, Scot Loftesness, and Dorn Stickle further
enhanced it and added XMODEM file transfer capability until it became known
as RBBS-PC CPC09 in May of 1983. At that time each feature or modification
was identified by a new version number; it still ran only under the BASIC
interpreter; and was both relatively slow (because of the interpreter) and
somewhat unstable (it would normally "crash" at least once each day).
Late in May of 1983, I asked Rich Schinnell if there was any "bulletin
board" software available for the IBM PC written in BASIC. Rich told me to
give Larry Jordan a call. Larry said that he was just getting CPC09 ready
to send to Rich Schinnell who at that time was Director of the Capital PC
User Group's Public Domain Software Library and that I could get it from
Rich. I did, and still have the diskette just as Rich sent it to me --
dated June 22, 1983.
Bulletin board systems, historically were the result of a single person or
small group of persons' efforts and tended to serve a very narrow interest
group -- typically those interested in the medium itself (i.e. PCs,
programming, communications, etc.). This was true up to and including
RBBS-PC CPC09. In fact, most of the incentive to get the public domain
versions of RBBS-PC (CPC09 and earlier) functioning was to introduce the
RBBS-PC CPC17-2A Page 9
XMODEM protocol to the IBM PC-based community. In this CPC09 was
successful and may have been the primary incentive for XMODEM to be
included in PC-TALK at all.
Since June of 1983 I have authored and released THIRTY-FOUR versions of
RBBS-PC and distributed them exclusively through the Capital PC User Group
under the limited license described in section 25 of this documentation.
At this time RBBS-PC appears to have become the "industry standard" for
IBM-type personal computer bulletin board systems. However, even from the
very beginning BBSs have excelled whenever:
a.) there was a geographically dispersed audience,
b.) with a need to exchange highly complex/technical information,
c.) in a timely and accurate manner.
RBBS-PC's impact has been to open an entirely new medium of communications
between people. Rather than as an end in and of itself, RBBS-PC has come
to serve as a means to an end -- the free exchange of ideas. On a
technical level it is certainly an example that shows "real programmers
can/do program in BASIC." I would like to think that RBBS-PC had something
to do with IBM and Microsoft coming out with new versions of the BASIC
compiler that support communications, sub-routines, local and global
variables, file-locking in a networking environment, etc.
RBBS-PC represents a fundamental cornerstone, not just a phase, in what can
be viewed as a "social renaissance." The three areas that I mentioned
earlier in which bulletin boards excel seem to ebb and flow within
communities and organizations. RBBS-PC provides an almost instantaneous
mechanism by which these needs can be met. Many of the Big 8 accounting
firms bring up RBBS-PC's just to fulfill one contract so that the various
geographically disbursed members on the contract can communicate across
time zones and continents. Unlike radio, newspapers, and television --
RBBS-PC provides a vehicle within which information can be EXCHANGED! That
is what makes RBBS-PC so unique. Because the exchange is written, it is
structured. Because it is structured, it can be thoughtful.
The "social renaissance" that RBBS-PC represents is the electronic
elimination of those barriers that had previously inhibited the "exchange"
of information within our society. RBBS-PC provides every personal
computer owner with his own "soap-box" in a national Hyde Park. Previously
the channels of communication had built-in barriers to "exchange"; with
RBBS-PC those barriers begin to cease to exist.
While only the most fanatical RBBS-PC trivia experts may be interested,
I've gone back and checked all the documentation and releases of RBBS-PC
that I've authored and here is the tedious chronology:
RBBS-PC CPC17-2A Page 10
RBBS-PC Initial Major Enhancements
Version Release
Number Date
CPC10.0 07/04/83 RBBS-PC first written to be compilable by IBM's BASIC
compiler, version 1.0
CPC11.0 08/10/83 RBBS-PC restructured so that all parameters were
external (i.e. in the RBBS-PC.DEF) allowing SYSOPs who
didn't want to spend the $300 for the BASIC compiler to
tailor RBBS-PC to their taste. CONFIG.BAS was first
written to generate RBBS-PC.DEF.
CPC11.1 09/15/83 Jon Martin contributed UTSPACE.OBJ, a sub-routine that
allowed the compiled version of RBBS-PC to determine
the amount of free space available for uploading.
CPC11.2 10/01/83 The error trapping within RBBS-PC was completely re-
written to be more comprehensive.
CPC12.0 10/28/83 Tree-structured file directories and the ability to
detect that RBBS-PC was in a "MultiLink" environment
were incorporated. "MultiLink" is a product of the
Software Link, Inc. which allows DOS 1.1, 2.0, 2.1, 3.0
and 3.1 to be "multi-tasking."
CPC12.1 12/18/83 The ability for a SYSOP who signed on remotely to drop
(Versions into DOS was added. Also the "New" command
was added "A" to "F")that allowed users to determine
what new files had been made available since the last
time they were on.
CPC12.2 04/08/84 The security system designed by Ken Goosens was
incorporated. RBBS-PC's security system has an elegance
"A" to "D")unmatched even by the largest mainframe.
Essentially the security system designed by Ken is
"self-locking lock" and, even though RBBS-PC's source
code is distributed, it's security system has remained
unbroken. Of course, SYSOPs who didn't adhere to RBBS-
PC's security structure have had their system "crashed"
and every SYSOP should operate as if the very next
caller could crash his system.
CPC12.3 11/11/84 This was almost as complete and as major a re-write of
RBBS-PC as CPC10.0 had been. Beginning with CPC12.3 up
"A" to "B")to nine RBBS-PCs can share the same files in
either a multi-tasking DOS environment (i.e. MultiLink
from the Software Link, Inc.) or in a local area
network environment (i.e. Corvus or Orchid).
CPC12.4 03/10/85 (Version A, A1, B) RBBS-PC'stature in the industry
became recognized when, as author of RBBS-PC, I was
granted a license by Microcom to incorporate their
proprietary MNP protocol and "B")into RBBS-PC. Almost
at the same time many manufactures recognized the
institution that RBBS-PC had become in
RBBS-PC CPC17-2A Page 11
RBBS-PC Initial Major Enhancements
Version Release
Number Date
our industry and elected to include "RBBS-PC
compatibility" in their minimum criteria for the
introduction of their new products. RBBS-PC's Vendor
Support Program is more fully explained in the RBBS-PC
documentation but one direct result of this was the
introduction of 300/1200/2400 BAUD support in CPC12.4A
before most such modems were generally available.
CPC12.5 07/14/85 (Versions A and B). RBBS-PC was enhanced to allow 36
copies of RBBS-PC to share the same files in a network
environment. RBBS-PC automatically answers the phone
and no longer requires each caller to enter up to 3
carriage returns in order for RBBS-PC to detect the
users baud rate and parity. Logon to RBBS-PC has been
made much more efficient with the USERS file no longer
being searched sequentially and the MESSAGES file no
longer being read three times. Version CPC12-5B,
released August 25, 1985, WAS THE LAST VERSION
COMPILABLE BY VERSION 1.0 OF THE IBM BASIC COMPILER!
CPC13.1 12/01/85 RBBS-PC was completely rewritten for both the IBM BASIC
compiler ($495 list price) and Microsoft's QuickBASIC
Version 1.0($99 list price). XMODEM with CRC was
added as a file-transfer protocol as well as the
ability to display on the color monitor of the PC
running RBBS-PC the color/graphics that the remote user
sees exactly as he sees them.
CPC14.1 03/16/86 (Versions A, B, C, and D) RBBS-PC's internal structure
was split into two parts - RBBS-BAS for the main-line
source code and logic, and a RBBS-SUB.BAS for commonly
called subroutines. This allows unlimited growth for
RBBS-PC by providing multiple "code segments" within
RBBS-PC. Support for on-line questionnaires,
auto-downloading, and the Columbia University-sponsored
KERMIT RBBS-PC Version protocol were also included as
well as the option to utilize assembly language
subroutines to increase for better performance over
their BASIC counterparts.
CPC15.1 03/15/87 RBBS-PC's internal structure continued to become
significantly more modularized and structured. Major
enhancements included a File Management System for
directories, additional file exchange protocols,
support for managing subscriptions, the ability to run
as a local application on a network, configurable
command letters, the ability to use any field or to
define a new field to identify callers, the ability to
individuate callers having the same ID, multiple
uploads on a single command line, new A)nswer and
V)erbose ARC list commands, context sensitive help,
and a new subsystem for software "libraries".
RBBS-PC CPC17-2A Page 12
RBBS-PC Initial Major Enhancements
Version Release
Number Date
CPC16.1 03/27/88 (Version A) RBBS-PC's internal structure continued to
become significantly more modularized and structured.
Major enhancements included the addition of
"sub-boards" (i.e. conferences with there own
bulletins, file areas, menus etc.), a programmable user
interface, the capability to have SYSOP-written
"sub-menus" for any command, the ability to hang off of
a public data network such as Compuserve's as a "node",
the incorporation of "personal downloads" (i.e. files
only specific individuals could list/download), the
ability to vary the amount of time a user has on the
system by the time of day the user logs on, the
capability of preventing any message (public or
private) from being read until the SYSOP has reviewed
it, an enhanced CONFIG utility with many more options,
YMODEM protocol built-in to RBBS-PC's main-line source
code, the ability to automatically add users to
conferences, and support for The Software Link's
MultiLink Version 4.0. Despite all these enhancements,
the BASIC RBBS-PC code was significantly enhanced such
that it only requires 268K to run -- allowing two
copies to run in multi-tasking DOS environments that
have 640K available.
CPC17.1 10/02/88 (Versions A, B, C, and D). RBBS-PC's internal
structure continued to become significantly more
modularized and structured. Major enhancements were
made in the System Support area, and the support for up
to eight communications ports;built-in interfaces to
external communications drivers based on Vince
Perriello's "FOSSIL" driver concepts; automatic
notification of the SYSOP when specific users log on;
improved automatic invocation of other applications
based on time of day; and SYSOP-selectable time delays
that users must wait before being able to download or
exit to a door. RBBS-PC's unique programmable user
interface (PUI) was enhanced to support "macros" (i.e.
use a single command to invoke any number of RBBS-PC
commands); SYSOP-selectable colors for all prompts and
messages (i.e. "colorization"); caller-selectable
"colorization" for text (i.e. color, bold or normal,
highlighting of text, etc.); and personalized text
files (i.e. text files that can dynamically adapt to
include information unique to each caller). The
messaging within RBBS-PC was enhanced to notify each
caller that logs on of the number of new messages and
how many are addressed to the caller for the
conferences to which the caller belongs. The text
editor function for messages was enhanced to allow any
character to be edited. RBBS- PC's standard "threaded"
message search now also scans the text of the messages
for matches. The RBBS-PC file subsystem was also
significantly enhanced to include an unlimited number
of installable protocols; batch downloading for such
protocols that support this (i.e. Zmodem, Megalink, and
Sealink); and control of callers ability to download
RBBS-PC CPC17-2A Page 13
based on either the number of characters or the ratio
of the callers downloads to uploads.
CPC17.2 05/28/89 (Version A). RBBS-PC's internal structure continued to
evolve as an example of a modularized and structured
BASIC program (20,000+ lines of source code). Major
enhancements consisted of increased flexibility in
invoking external applications (i.e. "DOORS"), on-line
questionnaires, RBBS-PC command "macros", the
integration (using the enhanced questionnaires and
"macros") of on-line data base facilities into RBBS-PC,
as well as extended support in RBBS-PC's file system to
support ANY file compaction technique (i.e. .ARC, .ZOO,
.ZIP, etc.) -- including allowing on-line users to list
text files that have been included within a compacted
file (thanks to Samuel Smith of The Tool Shop BBS).
RBBS-PC's "NETMAIL" interface to store and forward
messaging systems (i.e. FIDO MAIL, etc.) was enhanced.
Within the messaging subsystem numerous enhancements
were added including the ability to quote all or part
of a message that the caller was replying to. RBBS-
PC's file subsystem was improved to allow the system to
be configured such that all uploads were automatically
checked/verified (by whatever utility the SYSOP wanted
to use). RBBS-PC commitment to the concept of "users
helping users" was demonstrated once again with the
incorporation of support for the Computalker and
HEARSAY 1000 speech boards so that seeing-impaired
SYSOPS could hear (in a meaningful way) the activity
occurring on their RBBS-PC bulletin boards.
RBBS-PC CPC17-2A Page 14
During the evolution of RBBS-PC I have had the distinct privilege of
working with many contributors. Contributions have ranged from
suggestions, to software fixes, to significant enhancements, to improved
documentation. Some of the individuals named here have continued their
contributions to RBBS-PC even to the current release. Others have gone on
to pursue other interests. Where they are now, for the most part, I do not
know. Whether they have become heroes or villains, it is not important.
None should be forgotten. In their contributions to RBBS-PC's on-going
growth, each has paused to give of themselves without hope of reward by
practicing RBBS-PC's fundamental principle -- "users helping users." For
those who became less than they were, they should be remembered for what
they contributed. For those who have became more, I am continually
reminded that RBBS-PC has granted me the privilege of walking in the
company of giants.
While I have met very few of these people personally, those whose names I
remember are:
Doug Azzarito John German Blaine Korsel Samuel H. Smith
Jeff Batdorf Read Gilgen Matt Malden Gregg Snyder
Rod Bowman Ken Goosens Carl Margolis Robert Snyder
Randy Brodersen Ray Gwinn Jon Martin Carl Spencer
Mike Brown Dave Hacquebord Robert Mahoney David Staehlin
Sam Brown Steve Harrison Sidney Markowitz Stan Staten
Mike Button Gary Hoff Louie McCaw Dorn Stickle
Vince Castelli Gary Howrith Wes Meier Terry Steichen
Rob Cecchino Charlie Innusa John Morris Randy Sun
Tom Collins Loren Jones Bill Newkirk Yew Seng Tan
Drew Commins Larry Jordan Jeregen Nordhausen Terry Taylor
Ezra Conger Robert Jueneman Vince Perriello Jan Terpstra
Ed Copley Vern Kallegin Harvey Pierce David Terry
Richard Couture Dave Kleinschmidt Danny Plunkette Arnold Thomsen
Bob Cramer Steven Kling Lee Pollard Daan van der Weide
Dave Crane Ronald Koridon Jeff Porter Rick Wadowski
Everett Delano Steve Lieber James Reinder Clark Walker
Peter Eibl Steven Linhart Kurt Riegel Kim Wells
Warren Fox Joseph Lionelle Joel Ricketts Bob Westcott
John Friel Scott Loftesness Jacques Rodrique Robert White
Jim Fry Harry Logan Dick Rohradnz John Krytus
Asa Fulton Gene Lowry Rich Schinnell
Kent Galbraith James Ludwick Mark Seiden
Mitch Geier Kevin Lutz Andrew Silber
Special thanks goes to SYSOPs who helped sponsor enhancements to RBBS-PC,
including Ken Rogers of the United States Department of Commerce ECONOMIC
BULLETIN BOARD who encouraged configurable identification and
individuation, Loren Jones of The Center for Law and Computers at the
Illinois Institute of Technology's Chicago-Kent College of Law who
contributed to subscription support, John Rittwage of the American College
of Obstretricans and Gynecologists who helped support submenus and the
programmable user interface, and Brian Kelly of National Credit Appraisals
and Reporting, whose special needs prompted the development of personal
downloading.
To those whose names have not been mentioned -- apologies are extended
Take comfort in knowing that you live on in the work that you have wrought.
Jon Martin is primarily responsible for whatever technical excellence that
exists in RBBS-PC -- including the ability to have multiple RBBS-PC's share
the same files. I am not a programmer and didn't even know BASIC until I
RBBS-PC CPC17-2A Page 15
started writing RBBS-PC in June of 1983 and released RBBS-PC CPC10.0 in
July of 1983. Jon's commitment to RBBS-PC has at least matched my own.
Despite my own ineptness, Jon's patience, understanding, and technical
insights have been unfailing over these several years and, I would like
to both publicly acknowledge his contributions to RBBS-PC and express my
appreciation for his efforts on behalf of RBBS-PC.
I'd also like to mention Ken Goosens' efforts on behalf of RBBS-PC. Ken
took the time and trouble to wade through the BASIC source code and
incorporated the "security" system that exists within RBBS-PC today.
Anyone who looked at the source code prior to release CPC12-2A can
appreciate the magnitude of Ken's efforts. Over these last few years
Ken has continued to be an unending source of creative contributions to
RBBS-PC.
I wish space allowed me to chronicle the contributions of each of the
contributors to RBBS-PC. In an age of cynicism, RBBS-PC and the
Userware concept represents an opportunity for each of us to give back to
the world something a little better than when we found it. As I said in
section 1, this is something that I believe in strongly. To each of the
contributors to RBBS-PC I would like to say personally
"I am very proud of the company that RBBS-PC keeps."
All changes to RBBS-PC since CPC10.0 have been "ADDITIVE," meaning that
all capabilities in earlier versions are retained in the later versions.
RBBS-PC CPC17-2A Page 16
1.4 RBBS-PC Update Conventions
-------------------------------
RBBS-PC continues to evolve and be "debugged." The following coding
conventions have been helpful in the past and you are requested to observe
them in the future:
Updates consist of two types of ASCII files. One called xxxxxx.MRG which
are the BASIC source statements for the particular base-line source
code component of RBBS-PC to be updated. The lines that have been modified
are indicated as being so modified with a comment beginning in column 70 in
the format as follows:
4330 QUICK.SCAN.MESSAGES = FALSE ' CPC14-1D
These .MRG files can be applied to the base-line source code via Ken
Goosens Batch Line EDitor utility program (BLED). The BLED utility can
easily create .MRG files as it has both a file compare and file merge
function that is specifically geared to the new BASIC compiler's
capabilities that allow lines of source to be unnumbered.
The second file type is called xxxxxx.DOC. It describes on a line-by-line
basis the specific functions added or bug that was fixed. Obviously
xxxxxx can be anything you wish to name it. The second type of file is
what allows me to integrate several .MRG files and resolve whatever
conflicts that may exist.
Each incremental release of RBBS-PC beyond CPC17-2A will include updates to
the base-line documentation. This documentation update will include a new
Table of Contents which not only will be a complete replacement for the
base-line Table of Contents but which also will indicate (to the right of
the page numbers for each section that has been updated) the date of the
latest update (beyond the base-line).
The RBBS-PC naming conventions of CPCxx.x are roughly as follows:
1. If a "bug" is being fixed CPCxx.x will be given a .MRG file name such
as CPC14-1D.MRG with a corresponding CPC14-1D.DOC file describing the
changes. The first version of CPCxx.x is always "A". When you
logon to RBBS-PC the version will be displayed.
2. As bugs are reported and fixes found for the current release of RBBS-
PC, the source code corrections are distributed via an RFIXmmdd.ARC file.
This contains the necessary files to apply the "temporary fixes" against
the released version of the source code and re-compile the source code.
The recompiled .EXE files are distributed via a file named RFIX-EXE.ARC.
3. If a new feature or enhancement is added the last digit in the CPCxx.x
will be incremented by one (i.e. CPC12.2D was followed by CPC12.3A).
4. If a significant change to source code or logic occurs, the first two
digits of the release level will change (i.e. CPC14.1 was followed by
CPC15.1) The purpose of these conventions is to allow everyone to know
what RBBS-PC level they are running under (users as well as SYSOPs) and
understand the logic behind the changes/fixes as they occur so each SYSOP
can evaluate them for his own needs.
If you have comments or fixes please let me know so that they can be
reflected in the RBBS-PC program and shared with all other users. You
can do that by sending your changes by mail to:
RBBS-PC CPC17-2A Page 17
D. Thomas Mack
39 Cranbury Drive
Trumbull, Conneticut 06611
or uploading the changes to either of my RBBS-PC lines -- (203) 268-5315 or
(203) 268-0129.
While comments and suggestions are always welcome, those that are
accompanied by the RBBS-PC source code changes that implement them carry a
lot more weight than those that don't.
RBBS-PC CPC17-2A Page 18
1.5 Beta test sites, Where and Why
-----------------------------------
Many people volunteer to be "beta test" sites. It is fitting that those
who do know why each release of RBBS-PC is "beta tested" and what it takes
to be a "beta test" site.
The "beta test" process seeks to put each new release in as varied as an
environment as possible in order to resolve bugs in the new features as
well as assure that old bugs are not re-introduced by the addition of new
features. Beta testers take professional pride in what RBBS-PC is -- the
bulletin board standard for the IBM PC industry. Every beta tester
recognizes their responsibility to those who have contributed to RBBS-PC
and assumes the obligation of not letting them down by putting out a shoddy
product.
There are essentially only 13 criteria for becoming a beta test site:
1. A commitment to the "Userware" concept and the free exchange of
information.
2. A demonstrated knowledge of RBBS-PC's source code.
3. A willingness to work within the confines of the BASIC language.
4. A determination to avoid eliminating earlier functionalities within
RBBS-PC -- only add new ones.
5. A system on which unmodified versions of the new beta test version
of RBBS-PC will be run.
6. Being unwilling to release any part of what is being beta tested
to anyone else.
7. Accepting the risk of having your entire system and hard disk be
vulnerable to software flaws in the version of RBBS-PC being beta
tested.
8. Being willing to FIX the bugs you encounter -- simply reporting
them is not enough!
9. Living with the bugs that aren't fixed until they are fixed.
10. Being willing to call and discuss problems via voice (at your
expense -- not mine).
11. Being willing to call and download (almost daily during the "beta
test" period) 450K files also at your expense.
12. Living with the fact that whatever you are beta testing is not
going to be what is actually released and that you will probably
have to download what is actually released just like every one
else.
13. Being charitable about the author's programming skills.
Of all the criteria, it is the first one that is often the most difficult
requirement for those who would be "beta testers" to accept. The
commitment to the "Userware" concept requires that contributors to RBBS-PC
insist on accepting neither personal recognition, monetary reward, nor
benefit for their contributions -- except the self-satisfaction in knowing
that whatever they contributed made RBBS-PC (and hopefully) the PC world
RBBS-PC CPC17-2A Page 19
better than it might otherwise have been.
RBBS-PC does not exist to be a means to some individual's personal gain or
ego gratification. Too many people have contributed too selflessly of
themselves to RBBS-PC for this to ever be allowed to happen. For those for
whom this is too difficult a requirement, RBBS-PC's totally open
architecture provides the .MRG/.DOC mechanism (documented in section 1.4)
to allow individual authors of software modifications to RBBS-PC to both
achieve individual recognition and monetary reward from those RBBS-PC
SYSOPs who want to incorporate such merges and features into their versions
of RBBS-PC. Please note that distribution of .MRG and .DOC files is
totally consistent with the limited license that is granted with RBBS-PC.
Also note that distribution of modified versions of RBBS-PC is in violation
of RBBS-PC's limited license agreement.
Needless to say, those few who participate in each new release of RBBS-PC
typically are not the same people from release to release. This is because
of the intensity and time that the beta test period makes on the beta
testers. Another constraint is my abilities to adequately respond to more
than two or three beta testers at most. Finally, like owning a swimming
pool or a boat, everyone wants to be a beta tester once! There is little
glory and lots of pain. Jon and I usually divide up the beta testing
based on who lives east and west of the Mississippi river in order to have
as many beta test sites as possible. Ken has beta test sites all over the
United States.
Most of the credit for RBBS-PC CPC17-2A being better than the earlier
versions goes to the following beta testers:
Doug Azzarito, Palm Beach Gardens, Florida
Rod Bowman, Alta Loma, California
Mike Brown, Madison, Wisconsin
Paul Cangialosi, Woodbury, N.Y.
Juan Davila, Rio Piedro, Puerto Rico
Francis Dorer, Fairfax, Virginia
Dave Hacquebord, Tampa, Florida
Loren Jones, Chicago Illinois
Steven Kling, Brentwood , Maryland
John Krytus, Northwood, Ohio
Ron Kurr, Atlanta, Georgia
Terry Leckbee, Kansas City, Kansas
Gene Lowry, Tuscon, Arizona
Alex Mondale, Washington, D.C.
Willie Moore, Birmingham, Alabama
Lee Pollard, Oxon Hill, Maryland
Lyndon Payne, Plano, Texas
Malcom Ramsay, Roswell, Georgia
Steve Rogers, Lincoln, Nebraska
RoseMarie Siddiqui, Fairfax, Virginia
Phil Simerly, Chantilly, Virginia
Ray Smith, Carrollton, Texas
Greg & Bob Snyder, Burke, Virginia
Stan Staten, Gaithersburg, Maryland
Terry Taylor, San Leandro, California
Rick Wadowski, Clinton Twp, Michigan
Kim Wells, Largo, Maryland
RBBS-PC CPC17-2A Page 20
1.6 An Example of "Users Helping Users"
---------------------------------------
The ability to have multiple RBBS-PC's running concurrently -- either on a
single PC in a multitasking DOS environment or in a local area network, is
a concrete example of the concept of "users helping users" in action. This
ability was developed in support of the efforts of the State of West
Virginia Department of Education's "West Virginia Microcomputer Educational
Network" project. It is the first statewide microcomputer network and
encompasses all of the state's 1,125 schools in 55 different school
districts. Each school is intended to have the capability of
accommodating up to twenty IBM PC's in a local area network sharing a
common 20MB disk drive. As of June of 1984, 83 of the 1,125 schools had
such networks. Each PC can communicate with either the LAN, a central
library, or with other schools in order to share programs and materials.
The key component for this communication is RBBS-PC. In a presentation at
the U.S. Department of Education in Washington,D.C. on June 22, 1984, the
role RBBS-PC plays was described as follows:
"The medium that ties the entire system together -- that allows for
communication not only between one school and another but also between
schools and the central library -- is an electronic bulletin board
(RBBS-PC) This bulletin board will be in operation 24 hours a day at the
central site, with a similar bulletin board in operation at every school.
The local school bulletin board (RBBS-PC) could be accessed by students who
wish to review their lesson or take a test at home provided they had a
computer and a modem. Teachers could access their grade book or other
reports and lessons at home in preparation for the next school day.
Neither bulletin board system (RBBS-PC) requires personnel to answer
telephones or transmit files. They are both totally unmanned and operate
24 hours a day. No toll charges, of course, would be assessed for calling
the local school bulletin board and toll free 800 numbers are used for
accessing the central library."
The State of West Virginia arranged to have the vendors involved, IBM and
Corvus, make the appropriate equipment available on a "loan" basis so that
RBBS-PC could be developed to work in a local area network environment.
Since this project conformed so closely to the primary objectives of RBBS-
PC, we agreed to volunteer our time and take on the task of enhancing RBBS-
PC to allow up to nine (9) copies of RBBS-PC to execute concurrently
sharing many of the same files. On a single PC the maximum number of
concurrently running RBBS-PC's within the same DOS is limited only by:
a. the number of communications ports installed on the PC. IBM's limit is
two (COM1 and COM2), but other vendors supply "add-on" cards that provide
for up to eight or more communications ports on a single PC.
b. the number of communications ports that the BASIC compilers can read
and write to -- currently COM1 and COM2. IBM expanded the number of
communication ports available for the PS/2 models running PC-DOS 3.3.
RBBS-PC, beginning with CPC17-1A, can support additional communications
ports using FOSSIL drivers (see CONFIG parameter 221).
c.the number of concurrently running tasks that can be supported. IBM's
DOS is limited to one task. Other vendors provide "add-on" software to
IBM's DOS that provides for up to nine simultaneous tasks.
Within a network environment (i.e. multiple PC's linked together sharing
the same devices) the maximum number of concurrent RBBS-PC's is set by
RBBS-PC CPC17-2A Page 21
RBBS-PC's internal design to nine (9). This design was based on the fact
that anyone who wanted to run nine RBBS-PC's sharing the same set of files
would take the $46,000 needed to buy nine PC's with modems, network
interface cards, hard disk (at least 20MB) and purchase a minicomputer for
the same amount of money with more ports and storage. CPC13-1A was updated
to allow for 36 RBBS-PC'S to share the same files. For those interested
in further information on the State of West Virginia's Microcomputer
Educational Network, please contact:
Mr. John E. Cook
State of West Virginia Department of Education
1900 Washington Street East
Building 6, Room 221, Capital Complex
Charleston, West Virginia 25305
RBBS-PC CPC17-2A Page 22
2. SUMMARY OF RBBS-PC'S FEATURES
---------------------------------
During the past five years RBBS-PC has received many accolades. PC World
says "For electronic mail and bulletin board applications, the RBBS-PC
software is the best choice." EDP Analyzer says "RBBS-PC is the easiest to
use." RBBS-PC was the origin of PC Magazine's "Interactive Reader
Service." PC Magazine writes that RBBS-PC "is one of the most popular BBS
programs for the IBM PC" and has called RBBS-PC "an industry standard."
INFOWORLD, in a comparison of the most popular PC-based bulletin board
systems rated RBBS-PC the highest. Almost as if in confirmation, the U.S.
Department of Commerce's National Bureau of Standards report on Electronic
Bulletin Boards (publication NBSIR 86-3356) is devoted entirely to RBBS-PC.
RBBS-PC CPC17-2A is a significant enhancement to RBBS-PC and will be the
35th release of RBBS-PC CPCxx since I first published it in July of 1983.
RBBS-PC's policy of freely distributing the source code and continually
expanding it's range of capabilities throughout these last five years
represents not only the very best that is embodied in the concept of "users
helping users" but an expectation of excellence that NO product in the PC
industry has ever even approached. Here is a brief summary of the major
features of RBBS-PC.
RBBS-PC is the Remote Bulletin Board System for the IBM (or compatible)
personal computer. One of it's two primary purpose is to foster the free
exchange of information by allowing a microcomputer to be turned into a
"host" computer that people can "dial" into and use. It is a full
featured Bulletin Board System that supports:
o bulletins
o electronic mail (public and private)
o file exchange (uploading and downloading)
o on-line questionnaires based on "scripts" written by the SYSOP
o access to other applications from RBBS-PC (i.e. "dooring"), and
o letting authorized callers drop into the operating system to run
programs remotely from the caller's computer.
RBBS-PC is unique among host communications programs in that it is made
available under a limited license which requires that no charge for RBBS-PC
be levied -- only a minimal copying fee is permitted. RBBS-PC is unique
also in that ALL the source code for each release is also made available.
Those who wish to make contributions for RBBS-PC are asked to contribute
enhancements to RBBS-PC itself or contributions to the Capital PC User
Group. The author and contributors neither ask for nor accept money for
RBBS-PC. Upgrades, which average about two a year, are free. There is no
extra charge for a multi-user version. In fact there is only one RBBS-PC!
It can act as either a multi-user version or as a single-user system.
The purpose of this section is to provide a check list of RBBS-PC's major
features. After all, being free and including source code means that RBBS-
PC is the "industry standard" against which systems with similar functions
can be judged by end-users.
RBBS-PC has been around since 1983, and many people may not realize just
how extensively it has evolved and been enhanced over these last six years.
One advantage of distributing source code is that those who run RBBS-PC
systems are able to contribute improvements to it. Many people have
contributed to RBBS-PC over the years -- over 80 are listed in the RBBS-PC
documentation itself. The check list of major features and enhancements
that follows are just part of this on-going tradition.
RBBS-PC CPC17-2A Page 23
2.1 General
------------
Number of different "conferences" or messages areas -- unlimited
Number of messages that can be left -- unlimited
Number of files that can be uploaded or downloaded -- unlimited
Number of bulletins that can be posted by the SYSOP -- unlimited
Number of different file transfer protocols supported -- unlimited
Number of external applications that can be "DOORed" to -- unlimited
Number of on-line questionnaires -- unlimited
Number of questions in on-line questionnaires -- unlimited
Number of levels of security -- 66,536
Number of registered callers -- 32,767
Maximum number of characters in a single file -- 32,767
Maximum baud rate supported -- 19,200
Maximum number of characters in a single message -- 6,128
Maximum number of lines in a single message -- 99
Maximum number of simultaneous callers or users -- 36
Maximum number of communications ports supported on a one PC -- 8
Donation to CPCUG for a copy of RBBS-PC (4 diskettes) -- $16
Is the multi-user version included in the price -- yes
Is technical support included in the price -- yes
Is ALL source code distributed with each release -- yes
Are fixes and patches promptly made available -- yes
Is extensive technical documentation (220+ pages) including
file descriptions and record layouts distributed
with each release -- yes
Is there an OPTIONAL -- but professionally written and
published (Bantam Books ISBN 0-553-34552-4),
startup guide (430+ pages) for first time
bulletin board system operator (SYSOP) -- yes
RBBS-PC CPC17-2A Page 24
2.2 Messaging
--------------
Within a conference or message area:
The user's last message read is remembered -- yes
A user's security level can be unique to each conference -- yes
User's "preferences" (expert/novice) can be unique -- yes
A user can have privileges different from other areas -- yes
Conferences can be:
Public (anyone can join) -- yes
Private (only pre-registered users can join) -- yes
Semi-private (users with sufficient security can join) -- yes
Each conference or message area can have unique or different
Bulletins -- yes
On-line help files -- yes
Files available for downloading -- yes
mixtures of commands -- yes
menus -- yes
"Doors" (i.e. external applications that are exited to) -- yes
When callers log on they can (at the SYSOP's option) be
Automatically notified of all mail waiting for them -- yes
Automatically notified of only NEW mail waiting for them -- yes
Automatically notified which conference has mail for them -- yes
ONLY notified of mail in conferences the caller belongs to -- yes
Automatically notified of the messages that they have left -- yes
Automatically notified of the files they uploaded -- yes
Automatically notified of the files that they downloaded -- yes
Automatically notified of their profile of preferences -- yes
Automatically notified of any new "bulletins" -- yes
Automatically notified of any new files -- yes
Immediately download files -- yes
Immediately list the new bulletins -- yes
Immediately go directly to a specific area (turbo logon) -- yes
Specific messages can be:
Public (readable by all) -- yes
Private (to a specific individual) -- yes
To a "group" (readable by a specific collection of users) -- yes
Password protected (readable by supplying the password) -- yes
Public but available to others after the SYSOP reads it -- yes
Private but available to addressee after the SYSOP reads -- yes
Read by only those with a high enough security level -- yes
"Quick" scanned by subject only -- yes
"Quick" scanned with 69 messages displayed at a time -- yes
"Scanned" by sender, addressee, date, subject, and date/
time it was received by the addressee -- yes
"Scanned" with 23 messages displayed at a time -- yes
Read while "quick" scanning -- yes
Killed (i.e. deleted) one at a time -- yes
Killed in multiples -- yes
RBBS-PC CPC17-2A Page 25
When a message is read the software provides
Name of caller who entered the message -- yes
Date and time the message was entered -- yes
Name of caller to whom the message is addressed -- yes
Date and time the message was received -- yes
Subject of the message -- yes
Minimum security level needed to read the message -- yes
Messages can be searched via "threads" (for specific strings)
By message subject only (i.e. "static" threading) -- yes
By sender, receiver, subject, or (i.e. "dynamic" threading)-- yes
By text within a messages (i.e. "turbo" threading) -- yes
And read while threading without disturbing the search -- yes
Messages can be read
Forwards -- yes
Backwards -- yes
Singularly, by specific message number -- yes
Multiply, by specifying a series of message numbers -- yes
While "static" threading (i.e. matching on subject) -- yes
While "dynamic" threading (i.e. match on all header info) -- yes
While "turbo" threading (i.e. match on header or msg text) -- yes
That are only addressed TO the caller -- yes
That are only FROM the caller -- yes
Or re-read immediately after the last screen of a message
has been read (useful for long messages) -- yes
When entering or replying to a message
The message subject can be edited -- yes
The sender is notified if the addressee has not logged on -- yes
The caller can see if the mail has been received -- yes
After replying only the message header is displayed -- yes
After replying the caller can re-read the message -- yes
After replying the caller can kill the message replied to -- yes
The built-in message editor has
Automatic "word-wrap" -- yes
Allows any character as a separator for replacing strings -- yes
Text files to be uploaded remotely as a message -- yes
Text files to be imported by the local SYSOP -- yes
Lines to be deleted -- yes
Character strings to be searched and replaced -- yes
Margin widths that can be set by the caller -- yes
RBBS-PC CPC17-2A Page 26
2.3 File System Management and Exchange
---------------------------------------
The software automatically maintains a list of files
available to callers containing: -- yes
Name of the file -- yes
Size of the file -- yes
Date the file was created -- yes
One-line description of the file -- yes
Extended (multi-line) file description -- yes
Unlimited number of categories in which to classify files -- yes
Categories can have multiple line descriptions -- yes
A file can be associated with multiple categories providing
the capability of having a complex, tree
classification system for files -- yes
Callers can search the list of files available -- yes
By category -- yes
By date (most recent first) -- yes
By match on a string in one-line description -- yes
By match on a string in extended description -- yes
By "wildcards" -- yes
Callers who upload files can be asked to:
Categorize the uploaded file -- yes
Provide a one-line description of the file -- yes
Provide an extended description of the file -- yes
Authorized callers can add file descriptions without uploading-- yes
On an unsuccessful upload, the partial file is deleted -- yes
Files may be made available for "personal downloads" (i.e.
limited to a specific user or security level) -- yes
Archived files in ZIP, ARC, PAK, LZH format may be viewed by
the caller before downloading -- yes
Can install support for viewing any library format -- yes
Files may be separated into different DOS subdirectories
for callers to download from -- yes
The software can search 7,000 file descriptions in 60 seconds -- yes
Files can be downloaded when searching the list of files -- yes
File can be downloaded when listing the file descriptions -- yes
File listings can be resumed after a download -- yes
Multiple file downloads/uploads can be requested -- yes
RBBS-PC CPC17-2A Page 27
The software supports a "LIBRARY" file subsystem in which:
files of the same name are in different DOS subdirectories -- yes
files within a single DOS subdirectory can be .ARCed
together into a single file and downloaded -- yes
PC-SIG's CD-ROM can be made available for downloading -- yes
The software allows file transfers with both
"Internal" protocols (handled by RBBS-PC source code):
ASCII -- yes
Xmodem (checksum) -- yes
Xmodem (cyclical redundancy check) -- yes
Ymodem -- yes
and "External" protocols (i.e. handled by separate .EXE files):
Xmodem (checksum) -- yes
Xmodem (cyclical redundancy check) -- yes
Ymodem -- yes
YmodemG (used when MNP exists in the modem) -- yes
Imodem (used when MNP exists in the modem) -- yes
Windowed Xmodem -- yes
Kermit (as defined by Columbia University) -- yes
Windowed Kermit (as defined by The Source) -- yes
Zmodem (batch) -- yes
Sealink (by System Enhancements Associates) -- yes
Megalink -- yes
Unlimited number of external protocols can be added -- yes
Uploads can be made unavailable to callers for downloading -- yes
The SYSOP can specify:
A caller's minimum security level required to:
download files -- yes
upload files -- yes
overwrite existing files -- yes
categorize files -- yes
view uploaded files -- yes
An upload time credit be applied to a caller's session
time for time spent uploading -- yes
To apply the upload time credit to the maximum time per day-- yes
To automatically track the ratio of uploads/downloads
for all callers -- yes
for no callers -- yes
for each of the 65,000 security levels -- yes
To base the ratio of uploads to downloads on the
number of files transferred -- yes
or characters transferred -- yes
To allow callers access to file downloading based on the
caller's ratio of uploads to downloads -- yes
To allow callers to download files only after they
have been logged on a certain number of
minutes in each session -- yes
RBBS-PC CPC17-2A Page 28
2.4 The User Interface
----------------------
The interface shown to the caller allows the SYSOP to:
Substitute any letter for any command -- yes
Disable commands -- yes
Restrict specific commands to some security levels -- yes
Only show callers the commands available to them -- yes
Group commands into any sections -- yes
Specify how callers can move between sections -- yes
Group all commands into a single section -- yes
Create whatever prompt required to request user commands -- yes
Create any on-line help files -- yes
Create and design all menus -- yes
Make commands words (i.e. ENTER to enter a message) -- yes
Make commands single letters (i.e. "E" to enter a message) -- yes
Make commands a number (i.e. "1" to enter a message) -- yes
Make commands "macros" (i.e. a series of valid commands) -- yes
Make any item on a menu a "sub-menu" (i.e. selecting the
item displays another menu) -- yes
Have an unlimited number of submenus -- yes
Highlight strings found in searches with colors -- yes
Support colored prompts -- yes
Allow the prompts to be different colors -- yes
Allow menus to be ASCII, graphic, or colored/animated -- yes
Provide personalized text files (help, etc.) -- yes
User "friendly" features are that the software
Allows callers with unusual names (hyphenated) -- yes
Allows callers with similar names (J. Joe and J. M. Joe) -- yes
Allows the SYSOP to accept callers with the same names
(i.e. two John Jones) and still distinguish
between them by and field in the user record
(e.g. city/state) -- yes
Allows the prompt for the caller's first and last name
to be configurable by the SYSOP -- yes
Addresses the caller by the first name -- yes
Thanks the caller for uploads -- yes
Thanks the caller for messages -- yes
Thanks the caller for calling -- yes
Shows all defaults with [] (i.e. brackets) -- yes
Allows callers to "see and do" (i.e. not have to back out
of current section or command to do something) -- yes
Allows users to choose "novice" or "expert" modes -- yes
Provides short reminders of the commands in prompts -- yes
Provides on-line help for any command -- yes
Provide different help levels for "novice" and "experts" -- yes
Allows "command stacking" -- yes
Accepts unlimited type ahead from remote users -- yes
Provides a fast logon (directly locates the user's record) -- yes
Automatically pages the SYSOP when a specific user logs on -- yes
Prevents text from scrolling off the top of a user's screen-- yes
Wipes off prompt for next screen when caller continues -- yes
Takes the phone off the hook (so callers get a busy signal)
when the SYSOP is on locally doing maintenance -- yes
Informs the caller who "pages" the SYSOP of the times that
the SYSOP is normally available -- yes
Automatically logs off a caller who is inactive based on
a time period set by the SYSOP -- yes
Allows callers to see log of others who called that shows:
Name, date, and time other callers logged on -- yes
RBBS-PC CPC17-2A Page 29
City and state other callers were from -- yes
The software remembers the "preferences" set by the caller for:
Preferred file transfer protocol -- yes
Type of displays to be shown (ASCII, graphic, colors) -- yes
Lines per page (or screen) at the user's terminal -- yes
Margin width when entering messages -- yes
Upper case only or upper & lower case -- yes
A prompt bell with each command prompt -- yes
Padding end of lines with nulls (for hardcopy terminals) -- yes
Sending a line feed after every line -- yes
End-to-end echoing of characters (normally turned off by
a caller using networks that have relay delays
like PC-Pursuit) -- yes
"TurboKey" - acting on first letter entered at prompt -- yes
Reviewing files immediately upon logging on -- yes
RBBS-PC CPC17-2A Page 30
2.5 SYSOP Protection
--------------------
Because a SYSOP is absolutely and personally responsible for what is
communicated, the software protects the SYSOP by:
Recording all caller activity by caller, date, and time -- yes
Recording all communication among callers -- yes
Allowing the SYSOP to preview messages between callers -- yes
Allowing the SYSOP to preview files that are uploaded
before they are available to other callers -- yes
Automatically locking out callers who attempt to break
the system -- yes
Automatically denying access to callers who use names
that the SYSOP deems unacceptable -- yes
Allowing the SYSOP to "chat" directly on-line with
a caller -- yes
Preventing callers from chatting directly on-line
with each other outside of the SYSOP's control -- yes
Assigning each caller a specific security levels -- yes
Designating the minimum security level to use each command -- yes
Allowing the SYSOP to assign security levels to commands -- yes
Allowing the SYSOP to assign security levels to callers -- yes
Allowing the SYSOP to change any caller's security level -- yes
Allowing the SYSOP to assign a security levels to files
or groups of files that a caller must have in
order to access them -- yes
Allowing the SYSOP to require callers to know specific
passwords to access files or groups of files -- yes
Allowing the SYSOP to require callers to have BOTH a
specific security level AND know a specific
password in order to access a file or a
group of files -- yes
Allowing files to be protected (by requiring a password
and/or a minimum security level to access) based
on any combination of
subdirectory, -- yes
disk drive, -- yes
fully qualified names, -- yes
file extensions, -- yes
"wildcards" -- yes
Allowing "personal" files (i.e. files that only a specific
caller can access -- yes
Allowing each command to have a specific security level
that designates the minimum security level
needed to use the command -- yes
Automatically paging the SYSOP when a specific caller
logs on (without the caller knowing it) -- yes
Instantaneously allowing the SYSOP to lock out and
immediately disconnect an on-line caller -- yes
Enabling the SYSOP to display the on-line caller's
profile (i.e. all the information about the
caller) anytime a caller is on-line without
the caller being aware of it -- yes
RBBS-PC CPC17-2A Page 31
2.6 SYSOP Functions, Features, and Support
------------------------------------------
The software can be set to automatically drop to DOS at a
specific time of day (i.e. to do system maintenance, etc.) -- yes
The software can support and interface with store-and-forward
electronic mail systems (i.e. FIDO, BINKLEY TERM, SEADOG) -- yes
From the local keyboard's function keys, the software allows
the SYSOP to:
Exit to DOS -- yes
Toggle on or off if callers can "page" the SYSOP -- yes
Toggle the local print on and off -- yes
Log on locally to the system without calling in -- yes
Cause the system to immediately answer the phone -- yes
Enter input from the local keyboard on the caller's behalf -- yes
Grant a caller temporary SYSOP privileges -- yes
Temporarily increase or decrease a caller's security level
in increments of one or five -- yes
Permanently change a caller's security level -- yes
Temporarily change the elapsed time of the current
caller's session by one or five minutes -- yes
Display on the local screen what the caller sees -- yes
Invite the caller to "chat" with the SYSOP -- yes
Immediately lock out and log off the caller -- yes
Automatically log the SYSOP on next after current caller -- yes
The commands a SYSOP can execute locally or remotely are:
Exit to DOS -- yes
Toggle on or off if callers can "page" the SYSOP -- yes
List the comments that have been left to the SYSOP -- yes
List the log of the caller's activities that shows
Name, date, and time a caller logged on -- yes
City and state the caller was from -- yes
Date and time a caller logged off -- yes
If the caller was logged off due to inactivity -- yes
If the caller was logged off due to carrier lost -- yes
Baud rate and communications parity caller used -- yes
Files downloaded and uploaded -- yes
Success or failure of file transfers -- yes
Protocol used for file transfers -- yes
Number of characters transferred -- yes
Which bulletins a caller read -- yes
Which conferences a caller entered -- yes
Which messages a caller read -- yes
Which messages a caller left -- yes
Which messages a caller killed (i.e. deleted) -- yes
If the caller left a comment -- yes
If the phone was answered but nobody logged on -- yes
Caller was a newuser -- yes
A newuser changed their name/address -- yes
If caller changed password (and to what) -- yes
Questionnaire answered by the caller -- yes
Restore a message that was killed (i.e. deleted) -- yes
Erase the comments file -- yes
Maintain the file of users by:
Adding a user -- yes
Listing the file of users -- yes
Printing the file of users on a local printer -- yes
RBBS-PC CPC17-2A Page 32
Deleting a specific user's record -- yes
Scanning every user record for a specific string -- yes
Scanning every user record for a specific user -- yes
Modifying a specific user's password -- yes
Modifying a specific user's graphics preference -- yes
Setting a specific user's security level -- yes
Changing the beginning of a user's subscription -- yes
A SYSOP can identify callers by:
Any field in the user's record (i.e. account code) -- yes
Supplying a configurable prompt for the field used to
uniquely identify callers (i.e. employee number) -- yes
Allow interior blanks in caller's names -- yes
A SYSOP can have on-line questionnaires that
All users are required to answer -- yes
Only new users are required to answer -- yes
Are unlimited in number -- yes
Contain an unlimited number of questions within each -- yes
Record all answers to a different file -- yes
Automatically raise or lower a caller's security level
based on the caller's answers -- yes
The software supports file sharing (i.e. updating) in the
networks such as:
MultiLink (Version 4.0 and earlier) from the Software Link -- yes
OMNINET from Corvus -- yes
PC-NET from Orchid -- yes
DESQview from Quarterdeck -- yes
10NET from Fox Research -- yes
any environment compatible with NETBIOS from IBM -- yes
In a DoubleDOS environment, the software minimizes its
resource demand while waiting for work in order to free
as much power for other applications that are running -- yes
RBBS-PC CPC17-2A Page 33
2.7 System Access Management
----------------------------
The SYSOP can specify:
A maximum time per session for callers -- yes
A maximum time per day for callers -- yes
A different session time be allowed for each of the
65,000 different security levels -- yes
A different maximum time allowed callers on the system
each day based on the caller's security level -- yes
A minimum baud rate for new callers to logon with -- yes
A different minimum baud rate for existing callers to logon-- yes
A different maximum time per session based on time of day
(hour and minute) the user logged -- yes
A maximum time per day that is different from the maximum
time per session -- yes
To allow callers access to other applications (i.e.
doors) only after they have been logged on a
certain number of minutes in each session -- yes
To allow all callers access to the entire system (open) -- yes
To allow only pre-registered calls access to the entire
system (closed) -- yes
To allow automatic and instant access to the system for
for new users without pre-registering them
based on information pre-loaded into the system
(i.e. account codes, employee numbers, etc.) and
issued to callers before they access the system -- yes
The software provides an optional subscription management system that:
Is built-in -- yes
Is automatic (i.e. requires minimum SYSOP effort) -- yes
Is optional -- yes
Bases the subscriptions on the date of the caller's
first access to the system -- yes
Subscribers are given temporary, date-limited, "trial
periods" that allow them to access more features -- yes
The number of days prior to a caller being warned that the
subscription expires can be SYSOP-specified by -- yes
Automatically warns subscribers before their sub-
scriptions expire -- yes
Automatically reduces the subscribers system security
level upon subscription expiration -- yes
RBBS-PC CPC17-2A Page 34
2.8 Communications
------------------
The software will automatically
answer the phone and adjust to a caller's
communications settings -- yes
allow the modem to adjust to the caller's communications
settings while maintaining a higher data
transfer rate (19200 baud) between itself and
the modem to which it is attached -- yes
recognize a caller who calls at:
300 baud -- yes
1200 baud -- yes
2400 baud -- yes
4800 baud -- yes
9600 baud -- yes
19200 baud -- yes
recognize the MNP (automatic error correction) protocols
built into the modem it is attached to -- yes
recognize Hayes' pseudo LAP-B (automatic error correction)
protocol if the modem it is attached Hayes is a
Hayes modem with such protocol -- yes
recycle if no calls are received in a specified period -- yes
switch to N/8/1 for binary file transfers without
disconnecting the user -- yes
The software will allow a 300 baud caller to shift to
450 baud while on-line without disconnecting -- yes
The software supports modems that do not handle modem
commands but which can automatically answer the phone -- yes
The software handles "flow control" via:
Clear-to-send (CTS) -- yes
XON/XOFF -- yes
The software supports attachment directly to
a private branch exchange (PBX) -- yes
a public data network via an X.25 PAD -- yes
The software has optional, configurable modem commands to:
initialize the modem's firmware -- yes
initialize the modem each time the software recycles -- yes
set up the modem to answer the phone on each recycle -- yes
set the number of rings to answer the phone -- yes
answer the phone -- yes
take the phone off the hook -- yes
The software can be configured to wait a specified number of
seconds:
after initializing the modem on recycling -- yes
wait after issuing a modem command -- yes
before logging off an idle caller -- yes
after answering the phone for a carrier -- yes
The SYSOP can set the number of rings the software answers on -- yes
The software can be set to wait to issue modem commands
when the phone is not ringing -- yes
The software can utilize external communications drivers
RBBS-PC CPC17-2A Page 35
(for communications ports not supported by BASIC) -- yes
RBBS-PC CPC17-2A Page 36
2.9 "Base-Line" Hardware and Software Requirements
--------------------------------------------------
RBBS-PC is designed to run on an IBM Personal Computer running IBM's
Disk Operating System (DOS), communicating via an IBM Asynchronous
Communications Adapter and a Hayes Smartmodem modem. The following
equipment and software is the MINIMUM and the recommended configuration for
running RBBS-PC:
Minimum Recommended
System: IBM PC (Intel 8088 CPU) Any PC with an Intel 8088 CPU
that can run IBM's PC-DOS
Monitor: 80 column monochrome 80 column color monitor
Asynchronous
Communications
Adapter: RS-232 adapter with an IBM Asynchronous communications
Intel 8250 CPU adapter (serial port),
Modem: Any Hayes 1200 Smart- U.S. Robotics 9600 baud
modem (or 100% Hayes Courier HST
compatible!)
Telephone Line: Voice grade telephone Voice grade telephone
connection for modem connection for modem
Modem Cable: 25 pin RS-232 modem 25 pin RS-232 modem
cable (for external cable (for external
modem) modem)
RAM: 320K RAM available for 640K RAM available for
DOS and RBBS-PC DOS and RBBS-PC
Disk: one double-sided drive one high-density drive
(360K) (1.2 or 1.44 MB) and one
hard disk with at least 20MB
Operating System: MS-DOS/PC-DOS 2.0 PC-DOS 3.1 (or greater)
The .EXE files are distributed with RBBS-PC as well as the BASIC source
code so it is not necessary to have a BASIC Compiler to run RBBS-PC.
However, for those who would like to compile RBBS-PC from the source code
the recommended compiler is Microsoft's QuickBASIC 3.0.
The MINIMUM configuration that RBBS-PC can be run in is on an IBM PC that
has 320K of random access memory (RAM), one double-sided disk drive, an RS-
232 communications port with a Hayes modem and IBM's PC DOS 2.0 (or
higher). To run in 320K it is necessary to recompile RBBS-PC -- see
Appendix Y. As with ANY bulletin board system, the less disk space
available the more file maintenance the SYSOP must do. Also if you choose
to allow external file protocol transfers, an additional 192K of memory is
required if you SHELL to them rather than EXIT.
Beginning with RBBS-PC version CPC13-1A, RBBS-PC requires version 2.0 or
above of IBM's Disk Operating System (DOS). RBBS-PC will not run under the
BASIC interpreter. RBBS-PC runs under MS-DOS to the extent that the
executable code generated by the IBM/Microsoft BASIC compiler is compatible
with the multitude of different MS-DOS'. Do not expect RBBS-PC to run
under every variant of DOS on every IBM compatible.
If you have a second telephone installed specifically for RBBS-PC, ask
for a second voice grade telephone line. Data lines are very expensive
and are not necessary. The program requires the use of a Hayes
RBBS-PC CPC17-2A Page 37
Smartmodem (or one that is 100% Hayes compatible) in order to function
properly. If your non-Hayes modem doesn't work with RBBS-PC, send RBBS-PC
(source code and all) to the vendor and ask him to explain why it doesn't
work (i.e. why it is "incompatible" with the Hayes Smartmodem).
Callers who come in at even parity and 7 data bits, then try to change to
no parity and 8 data bits to use XMODEM, may have a problem if they
are using PC-TALK and a Hayes Smartmodem. Switch 1 on the caller's modem
has to be down (the factory default position) or the carrier will be
dropped when the communication parameters are switched. To avoid this
the PC-TALK caller will have to enter the escape code (factory setting
"+++"), reset the modem parameters with Alt-P and/or Alt-F, and then
return to the "connect" state with the command "ATO." Callers who wish
to communicate at 450 baud have to call in at 300 baud then switch to
450 using the N)ew baud selection from the "Utilities" menu.
RBBS-PC CPC17-2A Page 38
3. RBBS-PC's SUPPORT POLICIES
-----------------------------
3.1 RBBS-PC's Vendor Support Policy
-----------------------------------
The only reason RBBS-PC is "hardware-specific" to the IBM PC and the Hayes
Smartmodem is that these have pretty much set an industry standard (let's
not debate the issue of whether they have also set a "technology"
standard). If you follow the code in RBBS-PC closely, you will notice that
a great deal of effort was expended in order not to be "hardware-dependent"
on either the Hayes or the IBM PC.
The purposes of RBBS-PC are outlined in section 1 of the RBBS-PC
documentation. Those who contribute to RBBS-PC do so without any hope
of monetary reward. In fact, great lengths are taken to assure that
neither those involved with the development of RBBS-PC nor anyone who
distributes RBBS-PC does so for either personal gain or to promote a
specific product at the expense of other products.
If the hardware you are using is not part of the "base-line" hardware and
RBBS-PC doesn't work, your only recourse is to either modify RBBS-PC to
meet your particular hardware's needs (that's why the source code is
distributed) or contact your vendor and ask him to fix his hardware or
modify RBBS-PC (via .MRG/.DOC files) to support his hardware.
Since 1984 RBBS-PC became something of an "industry standard." As such
several manufacturers have requested that support for their particular
hardware and/or software be incorporated into RBBS-PC. These vendors have
had three choices:
1. Obtain a copy of the BASIC source code by sending $8 to the Capital PC
User Group's Software Exchange. The source code allows the vendor to
determine what is required to be "RBBS-PC compatible." Who better knows
the quirks of the manufacturer's product than the manufacturer?
RBBS-PC's limited license specifically permits the distribution of ".MRG"
files that would allow RBBS-PC to run with whatever idiomatic quirks a
specific vendor's product exhibited. The advantage to the manufacturer is
that he is in complete control and need not make the .MRG "universal" (i.e.
it need only support his product). The disadvantage is that new releases
of RBBS-PC come out every six to eight months and the vendor would have to
review each release to make sure the new releases and his .MRG files were
compatible. Of course, as with any other RBBS-PC operator, casual
telephone support is available to these vendors.
2. Supply the necessary equipment or software on a loan or gift basis to
be used in the testing of future releases of RBBS-PC. This approach has
been actively DISCOURAGED for three fundamental reasons.
1) The vendor perceives he has "paid" for on-going support by the loan
or donation of the product. This is not the case because RBBS-PC's
development is an all-volunteer activity. As such, neither I nor any of
the others involved with the development of RBBS-PC may have the time nor
expertise sufficient to assure compatibility of the specific vendor's
product with future releases of RBBS-PC. About all that can be done is to
give the vendor our "best effort" to assure compatibility, and advise when
it can not be made compatible.
2) The particular product may not have a universal applicability to
RBBS-PC users and (or) may not be of interest to those who regularly
contribute to the development of RBBS-PC. Both of these conditions must
exist before any vendor's product is incorporated into the RBBS-PC
RBBS-PC CPC17-2A Page 39
development cycle.
3) The price of the loaned or donated products (usually 3 to 5 such
products) in no way can even begin to compensate for the hundreds (if not
thousands) of development hours required to support other than "base-line"
hardware.
3. Establish an on-going institutional commitment to maintain a dialogue
between the vendor's engineering group and the RBBS-PC development team
along with supplying the necessary equipment or software on a loan or gift
basis to be used in the testing of future releases of RBBS-PC. This
approach has been actively ENCOURAGED for three different and fundamental
reasons.
1) The vendor overtly makes an institutional commitment to jointly
participate in the development of RBBS-PC. The vendor has the opportunity
to supplement the all-volunteer activity that is the basis for RBBS-PC
development by choosing to either modify their current or future products
to be compatible with RBBS-PC or to supply software that ensures
compatibility with RBBS-PC. This benefits all RBBS-PC users.
2) The particular products that fall into this category are required to
have a universal applicability to RBBS-PC users (i.e. multi-tasking DOS,
networking, 2400 or greater baud capability, error-free protocols, etc.).
Also a regular contributor to RBBS-PC's development must be geographically
located close to the vendor's development engineers to assure a timely
dialogue. Further any regular contributor to RBBS- PC's development who
accepts the responsibility for assuring RBBS-PC's compatibility with a
particular vendor's product must be willing to do so solely on a volunteer
basis over an extended period of time and in such a way as not to exclude
other vendor's products. Only when all these conditions exist is any
vendor's product a candidate to be incorporated into the RBBS-PC
development cycle. This assures that the RBBS-PC user community has a
feed-back mechanism to the vendor's product development and design teams
and the vendor is assured of a matching long-term commitment from the
RBBS-PC development team.
3) The vendor recognizes that the price of the loaned or donated
products (usually 3 to 5 such products) is minuscule compared with the
hundreds (if not thousands) of man-hours that may be required from both
the RBBS-PC development team as well as the vendor's engineers. This
assures that the vendors who choose this third approach are committed to
the PC user community. It is precisely this type of commitment that RBBS-
PC's USERWARE concept is designed to encourage (from both users and
vendors)
Vendors who have chosen to make this third type of commitment to RBBS-PC
and the PC user community deserve the respect and encouragement of every PC
user and are (alphabetically):
Ark Electronic Products, Inc.
325 W. Hibiscus Blvd.
Melbourne, Florida 32901
(305) 724-5260
Corvus Systems, Inc.
2100 Corvus Drive
San Jose, California 95124
(408) 559-7000
RBBS-PC CPC17-2A Page 40
The Forbin Project (c/o John Friel III)
4945 Colfax Avenue South
Minneapolis, MN 55409
Hayes Microcomputer Products, Inc.
5923 Peachtree Industrial Blvd.
Norcross, Georgia 30092
(404) 449-8791
International Business Machines Corporation
(Internal Zip Code 2900)
P.O. Box 1328
Boca Raton, Florida 33432
(305) 998-2000
Microcom, Inc.
1400A Providence Highway
Norwood, MA 02062
(617) 762-9310
Multi-Tech Systems, Inc.
82 Second Avenue, S.E.
New Brighton, Minnesota 55112
(612) 631-3550
Orchid Technology
4790 Westinghouse Drive
Fremont, CA 94539
(415) 490-8586
PC-SIG
1030 E. Duane Ave Suite D
Sunnyvale, CA 94086
(408) 730-9291
Prometheus Products Incorporated
4545 Cushing Parkway
Fremont, CA 94538
(415) 490-2370
Quarterdeck Office Systems
150 Pico Blvd.
Santa Monica, CA 90405
(213) 392-9701
Racal-Vadic
1525 McCarthy Blvd.
Milpitas, California 95035
(408) 774-0810
The Software Link, Inc.
8601 Dunwoody Place
Suite 336
Atlanta, GA 30338
(404) 998-0700
The Source
1616 Anderson Road
McLean, Virginia 22102
(703) 734-7500
RBBS-PC CPC17-2A Page 41
System Enhancement Associates
21 New Street
Wayne, NJ 07470
(201) 473-5153
U.S. Robotics, Inc.
Skokie, Illinois 60076
(312) 982-5010
Users who feel that they have benefited or who appreciate such commitment
to the user community should write or call the above vendors and tell them
so, especially if such a commitment influenced the purchase of their
products. Similarly, if any user feels that other vendor should make a
similar commitment to RBBS-PC and the user community, write to that vendor
and send a copy of your letter to the following address:
D. Thomas Mack
39 Cranbury Drive
Trumbull, Conneticut 06611
Section 21 describes the RBBS-PC standard interface for protocol drivers.
All vendors of proprietary protocols who would like to have them added to
future releases of RBBS-PC need do is simply conform to this interface.
RBBS-PC CPC17-2A Page 42
3.2 RBBS-PC's User Support Policy
---------------------------------
RBBS-PC is an all-volunteer effort on my part. Professionally I am not a
programmer (as anyone who has looked at the source code can testify) nor an
"expert/guru" on personal computers. Since I am not independently wealthy,
I have a full time job (unrelated to PC's). As with most other folks, I'm
also busy raising a family. What time I can spare from these other
activities I am glad to donate to answer questions about RBBS-PC as I
believe (somewhat fanatically) in the Userware concept.
However, if you have questions regarding something other than the "base-
line" hardware and software requirements outlined in section 2.9, DON'T
CALL ME. I probably can't help you anyway and even if I do venture some
advice it will probably be wrong. One of the axioms of the "Userware"
concept is that every user should be able to help themselves -- that's why
there are more than two hundred pages of documentation and the source code
is freely distributed (under a limited license and copyrighted).
The only calls that I truly appreciate are those that reveal BOTH a problem
and a solution. These I am more than happy to share with anyone and are
included in RBBS-PC (either the documentation, the software, or both) as
rapidly as possible. Of course, if you encounter a problem and
1. read and re-read the documentation,
2. spend days and days attempting to isolate it,
3. called other SYSOPs and asked their help,
4. looked up any error messages you encountered (they are in the
BASIC manual that comes with your IBM PC's DOS),
5. know what version of RBBS-PC that you are running,
6. know what version of CONFIG that you are running,
7. eliminated all other software from your environment,
and still can not get RBBS-PC to work, I am most happy to lend whatever
telephone advice I can.
RBBS-PC'S Technical Support phone number is (203) 268-9656. If you get the
answering machine please leave your name and phone number where you can be
reached in the evenings. (Do not leave Data numbers, Voice only please!)
Someone will return your call (COLLECT) to try and help you with your
problem.
In this regard, it may help to remember that there are only two types of
problems -- MY problems (which are the ones that I can solve) and OTHER
PEOPLE's problems (which are the ones that I can't solve).
RBBS-PC CPC17-2A Page 43
4. HOW TO GET A COPY OF RBBS-PC SENT TO YOU
-------------------------------------------
RBBS-PC can be obtained by sending a check for $8 to the
Capital PC Software Exchange
P.O. Box 6128
Silver Spring MD 20906.
RBBS-PC is distributed on two double-sided, 9-sector, diskettes. Allow 3 to
4 weeks for delivery -- remember this is an all-volunteer effort. Be sure
to specify RBBS-PC CPC17-2A on "diskette # 18". If you would like the
RBBS-PC source code and some utilities that other SYSOPs have found useful,
send a second $8 with your order and ask for "diskette #18S."
Version CPC17-2A of RBBS-PC's .EXE file is distributed after having been
compiled with QuickBASIC Version 3.00 compiler that had the DTR patch
described in Appendix T applied to it.
The exigencies of RBBS-PC software releases may mean that diskette 18
contains an earlier version of RBBS-PC than CPC17-2A (either you bought
diskette 18 sometime ago or there has been not enough time for diskette 18
to be updated to this most current version). Not to fear! Your $8 has
not been wasted. At least three bulletin boards keep the most current
copies of RBBS-PC for downloading. They are:
(203) 268-5315 --+
+---- East Coast (Trumbull, Conneticut),
(203) 268-0129 --+
(703) 978-6360 ------- East Coast (Fairfax, Virginia),
(415) 689-2090 ------- West Coast (Concord, California).
RBBS-PC CPC17-2A Page 44
5. FILES RBBS-PC USES
---------------------
There are essentially two types of files that RBBS-PC uses -- "system" and
"text" files. "System" files are defined as random files that RBBS-PC
reads and writes to. "Text" files are defined as files that RBBS-PC
primarily reads from. Text files can be edited externally to RBBS-PC with
most text editors that can handle ASCII files. Either type of file can be
"static" or "variable" in length. By "static" it is meant that these files
have a pre-defined length beyond which RBBS-PC does not extend them.
Similarly, "variable" length files are defined as those files whose length
is dynamically increased by RBBS-PC. In a multiple RBBS-PC environment
only the "static" length files can be shared SAFELY among the various RBBS-
PC's. The following table summarizes this using the default file names:
"Static" Length Files "Variable" Length Files
-----
/|\ MESSAGES CALLERS ARCWORKx.DEF
| USERS COMMENTS NODExWRK
System MESSAGES.BAK upload disk RBBSxF1.DEF
Files USERS.BAK DKxxxx.ARC DORINFOx.DEF
| RBBSxPC.DEF upload disk
\|/ 99.DIR (upload directory)
-----
The following "text files" are "static" in length and can be shared safely:
----- NEWUSER RBBS-CDR.DEF
/|\ MENU0 --> MENUA LGx.DEF
| BULLET, BULLET1 --> BULLETn AUTOPAGE.DEF
| DIR.DIR, aa.DIR --> bb.DIR CONFMAIL.DEF
| CDR.CDR, aa.CDR --> bb.CDR RBBS-CDR.DEF
Text FILESEC PROTO.DEF
Files CONFENCE RBBS-REG.DEF
| xxxx.PUI PRELOG.DEF
| PASSWRDS EPILOG.DEF
| xx.HLP PRIVATE.DEF
| HELPxx AUTOPAGE.DEF
\|/ TRASHCAN RBBSxTM.DEF
----- WELCOME
In a CORVUS network environment any of the "static" length files can be
shared on a common volume and ALL of the "variable" length files must be
segregated on volumes unique to each copy of RBBS-PC. RBBS-PC issues the
NAME function of BASIC in order to determine if a file exists. Because of
this, all the volumes accessed by any RBBS-PC in a CORVUS network must be
designated "read/write." Therefore, you must be very careful when running
CONFIG.BAS. CONFIG creates the definition file (RBBSxPC.DEF) for each copy
of RBBS-PC.
In a MultiLink (from the Software Link, Inc.) environment and in Orchid's
PC-NET environment the vendors claim that not only all the "static" length
files can be shared on a common volume but also some of the "variable"
length files can be shared. However, if you want to be as conservative as
possible, run RBBS-PC in ALL environments as if it where running in a
CORVUS network environment. However, if you rely on the vendors claims, in
either a MultiLink or PC-NET environment, when running CONFIG.BAS which
creates the definition file (RBBSxPC.DEF) for each copy of RBBS-PC, you
must be careful to put at least the CALLERS file on an unshared volume.
RBBS-PC CPC17-2A Page 45
5.1 RBBS-PC System Files
-------------------------
As shown above, "system" files are both static and variable in length. The
system files used by RBBS-PC are:
MESSAGES - This file is a random file that contains the message text for
the RBBS-PC system. The first record in the file contains the RBBS-PC
"checkpoint" record. The records immediately following this first record
are the RBBS-PC "node" records. The rest of the file consists of message
header records which are followed by the message text for that
header. Appendix A describes the fields and their uses within the various
type of records of the messages file. RBBS-PC expects the MESSAGES file to
exist and to have been created by the CONFIG utility. If CONFIG does not
find the MESSAGES file or it finds one in pre-CPC12-3A format, it will
create it and initialize it to the size the SYSOP specifies. Because of
the fixed length records in this file, it should not be created or edited
outside CONFIG. When the SYSOP "packs" the message file using CONFIG,
the file MESSAGES.BAK is created to hold the old messages in case the
"pack" is unsuccessful (i.e. not enough space to duplicate the message
file). If the disk fills up during the pack function RBBS-PC will
recover the message file using MESSAGES.BAK. When the messages file is
successfully packed, the pre-packed messages file is renamed
MESSAGES.OLD and the temporary file MESSAGES.BAK is renamed MESSAGES. The
MESSAGES file should only be "packed" in a multiple RBBS-PC
environment when there are no RBBS-PCs active. The MESSAGES file can be
shared among multiple RBBS-PCs.
USERS - The USERS file is a random access file that has a record for each
user who used the system. The record contains a profile for each user who
has logged onto RBBS-PC. Appendix A describes the format of the records
within the USERS file. The records are 128 bytes in length and are
automatically maintained by RBBS-PC. The SYSOP can do some limited
editing using SYSOP function 5. To initialize the system simply ERASE
this file. RBBS-PC expects the USERS file to exist. If the utility
CONFIG does not find the file on the system it will create it to the size
specified by the SYSOP. The USERS file should not be created or
edited outside CONFIG. When the SYSOP "packs" the user file using
CONFIG, the file USERS.BAK is created to hold the old users in case the
"pack" is unsuccessful (i.e. not enough space to duplicate the users
file). If the disk fills up during the pack function RBBS- PC will
recover the USERS file with USERS.BAK. When the users file is
successfully packed, the pre-packed users file is renamed USERS.OLD and the
temporary file USERS.BAK is renamed USERS. The USERS file should only be
"packed" in a multiple RBBS-PC environment when there are no RBBS-PC's
active. The USERS file can be shared among multiple RBBS-PC's.
CALLERS - This file is a random file that contains a log of all callers as
they log on to the system along with callers city and state, the date and
the time. The names are added to the end of the file as well as are the
names of the files uploaded/downloaded by the caller. If the file is
not found RBBS-PC will create a new one. The file should be ERASED to
clear the log. The CALLERS file cannot be shared among multiple RBBS-PC's.
COMMENTS - This file is a sequential file that contains any comments that
have been left by users for the SYSOP. The file can be scanned by a SYSOP
function or it can be TYPEd or edited outside the RBBS-PC system. A
SYSOP function is available to delete this file, or it can be emptied
outside of DOS. The file will be created by RBBS-PC if it is not found.
The COMMENTS file cannot be shared among multiple RBBS-PC's using CORVUS'
"OMNINET". This file can be shared using MultiLink or Orchid.
RBBS-PC CPC17-2A Page 46
99.DIR- The default filename on the upload disk that is to have the name,
file size, date, and description appended to it of files that have been
uploaded. The 99.DIR file cannot be shared among multiple RBBS-PC's using
CORVUS's "OMNINET", but can be shared using MultiLink or Orchid.
RBBS-PC.DEF - This is an ASCII text file created as output by the
CONFIG program. It contains the configuration parameters for the RBBS-PC.
It is read by RBBS-PC to determine the configuration settings tailored to
your RBBS-PC. In a multiple RBBS-PC environment the definition file for
each RBBS-PC is named RBBSxPC.DEF where "x" is a number 1 through 9 , 0
(for the tenth copy), and A through Z (for the eleventh through 36th copy)
corresponding to which copy RBBS-PC it describes. In a single RBBS-PC
environment the name will be RBBS-PC.DEF.
RBBS-PC displays on line 25 the status of those files which must be locked
in a network environment. The lock status of the message file is displayed
in positions 68 & 69. The lock status of the user file is displayed in
positions 71 & 72. The lock block status is displayed in positions 74 & 75
and comments/uploads share positions 77 & 78. The letter "U" in the first
position shows that the file is currently "UNLOCKED". The letter "L" in
the first position indicates that the file is "LOCKED".
ARCWORKx.DEF - This file is created as output by the file view command
and contains the contents of the archived file being inquired against.
QMXFER.ERR - This file is created as output by QMXFER.COM to notify RBBS-
PC of the results of an external file protocol transfer.
DKxxxx.ARC - This file is created as output by the Library Sub-System
archive program. This work file is deleted each time RBBS-PC recycles.
DORINFOx.DEF - This file is created by RBBS-PC when a caller exits to a
DOOR. It contains information about the caller needed by a "DOOR". It
consists of an twelve record file that contains the following
information:
1. The name of the RBBS-PC system
2. The SYSOP's first name
3. The SYSOP's last name
4. The communications port being used
5. The baud rate and parity the caller logged on at and the baud
rate that RBBS-PC is connected to the modem at
6. The network type (if any) RBBS-PC is running in
7. The caller's first name
8. The caller's last name
9. The city and state the caller is from
10. The caller's graphics preferences
11. The caller's security level
RBBS-PC CPC17-2A Page 47
12. The caller's time remaining in the current session
NODExWRK -- This file is created by RBBS-PC when a caller exits to an
external protocol to do "batch" downloads. It contains a list of fully
qualified file names to be downloaded.
RBBS-PC CPC17-2A Page 48
5.2 RBBS-PC Text Files
-----------------------
Similarly, the RBBS-PC "text" files are both static and variable in length.
The "text" files used by RBBS-PC are:
BULLET - This is a text menu file that is printed following the WELCOME
file when a user first enters the system. It must be present if "CONFIG
Utility parameter 43" is greater than 1. It can also be called from the
main menu with the <B>ulletins command.
BULLET1 --> n -- There can be 1 to 99 "bulletins". RBBS-PC will check for
the existence of a file whose name consists of the prefix given by
parameter 44 of CONFIG.BAS appended with the bulletin number and using
parameter 41 of CONFIG.BAS to determine the drive to find the bulletin on.
Users can elect to have displayed two different types of "graphics" files
for such standard RBBS-PC system files as HELPxx, BULLET, MENU's, etc. In
order for a user to see either of these two different types of "graphics"
files, the following must have occurred:
logged on N/8/1,
requested graphics (either full ASCII or "color/music"), and
the file must exist and the filename end in either:
"G" for files containing the graphic ASCII characters
whose values are in the range 129 to 256, or
"C" for files containing combinations of the full
256 characters that the caller's communication
software can interpret and translate into colors
and music (e.g. PCTK666, QMODEM, and EXECPCT).
RBBS-PC will check to see if a "graphics" files exists by appending a "G"
or "C" to the file name. If such a file can't be found, RBBS-PC will check
to see if a non-graphics file exists (i.e. one without the "G"). RBBS-PC
will display the first file it finds or a message that the file can not be
found.
DIR.DIR, aa.DIR --> nn.DIR -- At least one DIR.DIR file has to be
present on one of the drives available for downloading. Alternative
directories, aa.DIR --> nn.DIR (see section 13), should be meaningful and
should be reflected in the DIR file.
CDR.CDR, aa.CDR --> nn.CDR -- At least one CDR.CDR file has to be
present on one of the drives available for downloading if the
Library Sub-System support has been activated. Alternative
directories, aa.CDR --> nn.CDR, should be meaningful and should be
reflected in the CDR.CDR file.
FILESEC - is more fully described in section 17.4 on security.
HELP -- There is a help file for each command which has the format
xy.HLP, where x is the first letter of the section (M,F,U) and y is the
command letter. There are also the following special help files:
MAIN.HLP -text file that is printed when <H>elp is requested on the main
function prompt. It contains command information.
HELP03 -text file that describes the message protection options when <?>
is entered after the message <E>nter command is executed at the main
message menu.
HELP04 -text file that describes the message entry subfunctions when <?>
RBBS-PC CPC17-2A Page 49
is entered at the subfunction prompt.
FILE.HLP -text file that is printed when <H>elp is entered in the files
subsystem function prompt.
UTIL.HLP - text file printed when <H>elp is requested in the utility
subsystem function prompt.
HELP09 -text file printed when <H>elp is requested for type of graphics a
user wants (none, ASCII, color/music).
LIBR.HLP - text file that is printed when <H>elp is entered within the
library subsystem.
SMARTTXT.HLP - text file that illustrates the use of embedded commands
within any text file displayed by RBBS-PC that causes the text to appear
personalized to the caller. See section 8.9 for a fuller description of
this RBBS-PC feature.
UPCAT.HLP -- This is the file that is used to help user's categorized their
up-uploads.
SECVIO.HLP -- If this file is present, it is shown to the caller each
time a security violation occurs.
MENU0->A -- contain the local SYSOP menu and menu of various commands for
the subsystems. It is recommended that these be placed on an electronic
disk drive (i.e. RAM) rather than on a floppy or hard drive.
NEWUSER - This is a text file that is displayed for new users just before
registration occurs.
PASSWRDS - is more fully described in section 17.3 on security.
PRELOG - A text file displayed to callers prior to asking for their
first/last name and password.
RBBS-CDR.DEF - is a text file that contains the disk numbers, paths and
disk titles of disks available to the Library subsystem. The format of the
file is described in section 13.6. The RBBS-CDR.DEF (and matching FMS
directory) file can be downloaded from Jon Martins' system. It is not
distributed with RBBS-PC because of it's size (500K).
TRASHCAN - is a text file that contains names that the SYSOP finds
objectionable and does not want used as either a users first or last name.
RBBS-PC uses this file, if it exists, to deny access to anyone using one of
these names for either their first or last name.
WELCOME - is a text file that a user first sees upon logging onto the
system. It must be present, and it should be modified to identify your
system. Similarly each "conference" can have a "welcome" file by having a
file whose last character ended in a "w" (i.e. conference "RBBS" would have
a message file named RBBSM.DEF and a user file named RBBSU.DEF if it where
a "private" conference and a welcome file named RBBSW.DEF).
CONFENCE - A text file displayed to users who issue the J)oin function from
the main menu. It can be created by any text editor that can create an
ASCII file and should contain a list of the available conferences.
LGx.DEF - This is the file displayed to users based on security level when
RBBS-PC CPC17-2A Page 50
the caller logs on. The "x" defines the security level of the users who
would see this file. A SYSOP can "lock out" users (i.e. give them a
security level below the minimum to logon on) for various reasons. This
allows the SYSOP to provide an explanation for callers whose security level
falls below the minimum to log on. It can also be used to provide a
"personalized" welcome to users who have a specific security level.
Callers see the LGx.DEF file corresponding to their assigned security
levels. Some examples are:
Security File Text that might be included in the file
Level Name
9 LG9.DEF "Hi, nice to have another SYSOP call in."
6 LG6.DEF "Registered users are the most appreciated."
4 LG4.DEF "Too many security violations."
-1 LG-1.DEF "You behavior has been inappropriate."
-99 LG-99.DEF "You have never uploaded anything."
RBBSxF1.DEF -- This is the file dynamically created when the local SYSOP
wants to drop to DOS.
EPILOG.DEF -- This is the questionnaire that is shown to users who log
off. It can be either an extensive "poll" (which frequent users would find
tedious) or a simple thank you.
PRIVATE.DEF -- This file contains the information used for "personal
downloading", described in section 13.7.
RBBS-REG.DEF -- This is the questionnaire that is asked of all new users
who log on. It is only seen by new users and can be as extensive as you
may like or you can have none at all.
MAIN.PUI -- This is the programmable user interface file that allows the
SYSOP to structure the RBBS-PC commands as desired.
CONFMAIL.DEF -- This is a text file setup by the SYSOP to notify callers of
the mail they have waiting in specific (or all) conferences. See section
18.1 for a more comprehensive description of this feature.
AUTOPAGE.DEF -- This is a text file setup by the SYSOP that informs RBBS-PC
of which caller, callers, or group of callers that the system should
automatically "page" the SYSOP as soon as they log on. See section 8.11
for a more comprehensive description of this feature.
RBBS-PC CPC17-2A Page 51
6. INSTALLING RBBS-PC FOR THE FIRST TIME
----------------------------------------
RBBS-PC, unlike simpler applications such as games and utilities, is a
complex application that requires someone who wishes to set up RBBS-PC to
already be familiar with modems and PC communications. This section is
intended to provide a step-by-step approach to setting up RBBS-PC for the
first time. Follow the steps thoughtfully! Do not proceed to subsequent
steps until you understand all the previous steps.
However, for those who are NOT familiar with electronic bulletin board
systems in general, a much better introduction to installing RBBS-PC is
contained in the book "Electronic Bulletin Board Starter Kit" by Charles
Bowen and David Peyton, published by Bantam Books. The book does in 436
pages what the next few pages attempt to do. It is a superb guide for
someone who has never setup a bulletin board system and/or is not
knowledgeable about PC or asynchronous communications. The book comes
complete with an extensive index as well as a copy of RBBS-PC CPC Version
15-1C and, of course, the associated source code. Since all versions of
RBBS-PC are upward compatible, this book serves equally well as a guide for
the uninitiated to all subsequent versions of RBBS-PC. This book guides
the uninitiated potential SYSOP in easy stages from unwrapping the two
diskettes that are included with the book to operating the more advance
features of RBBS-PC. The book was published by Bantam Books in August of
1988, ISBN 0-553-34552-4, and can be found in most technical book and
computer stores. It addresses the topic of installing an electronic
bulletin board system in a far better way than this "Technical Reference
Guide" could (or would).
Because RBBS-PC attempts to provide SYSOPs the maximum flexibility, it is
perfectly possible for those setting RBBS-PC up for the first time to shoot
themselves in the foot. Be patient with yourself. Remember that things
worth achieving usually are not obtainable without effort.
Because of the prevalence of hard disk usage these days, the following
assumptions about the hardware to be used to set up RBBS-PC has been made:
1. IBM PC or XT with a hard disk (previously formatted!)
2. Minimum RAM of 320k (only if recompiled -- see Appendix Y)
3. Hayes external modem
4. Dedicated 'voice grade' phone line
SOFTWARE REQUIRED
1. IBM PC-DOS or MS-DOS 2.0 or higher
2. RBBS-PC.EXE - the main program
3. CONFIG.EXE - the setup program
4. RBBSDOCx.DOC - the documentation files
5. ALL of the RBBS-PC text files: MENU1 - MENU5, HELPxx, *.HLP,
WELCOME, DIR.DIR, xxxxxxxx.DIR, PRELOG, BULLET, BULLETxx
6. A text editor (PE2, WS non-doc, EDLIN, etc.) to create other
useful/needed text files. Your editor MUST be capable of
saving spaces (hex 20's) as characters and not substitute
tab characters for strings of spaces. Those mentioned
above ARE.
7. WATCHDGx.COM - an external carrier monitor program where
x =COMx and which is available from most
RBBS-PC systems.
1. [ ] PRINT A COPY OF THE DOCUMENTATION!
RBBS-PC CPC17-2A Page 52
2. [ ] Have dinner or take a nap while the previous step executes.
3. [ ] Create a sub-directory in which RBBS-PC is to reside. MKDIR
\RBBS.
4. [ ] Change current directory to the newly created directory CHDIR
\RBBS.
5. [ ] Create a sub-directory called NEW for your uploads.
6. [ ] Create any other sub-directories you desire to hold downloads
MKDIR TURBO
MKDIR PATCHES
MKDIR UTILS etc. as sub-directories of C:\RBBS
The following is a suggested 'layout' of the sub-directories and
files which comprise RBBS-PC.
C:\
COMMAND.COM
\DOS
\RBBS
RBBS.BAT
RBBS-PC.EXE
CONFIG.EXE
WATCHDGx.COM
MESSAGES
USERS
MENU1->MENU5
MENUA
HELPxx
*.HLP
WELCOME
PRELOG (OPTIONAL)
BULLET
BULLET1 (HOWEVER MANY)
FILESEC
PRIVATE.DEF (OPTIONAL)
RBBS-CDR.DEF (OPTIONAL)
LGx.DEF (OPTIONAL)
AUTOPAGE.DEF (OPTIONAL)
CONFMAIL.DEF (OPTIONAL)
PROTO.DEF (OPTIONAL)
PASSWRDS
TRASHCAN
CALLERS (WRITTEN BY RBBS-PC)
COMMENTS (IF NOT USING COMMENTS AS MESSAGES WILL BE
CREATED BY RBBS-PC)
\RBBS\NEW
UPLOADS.DIR (Whatever your users upload will go here)
\RBBS\DIR
DIR.DIR
TURBO.DIR
UTILS.DIR
CDR.CDR (OPTIONAL FOR LIBRARY)
100.CDR (OPTIONAL FOR LIBRARY)
101.CDR (OPTIONAL FOR LIBRARY)
\RBBS\TURBO (What ever your users can download must be put here)
\RBBS\PATCHES (Or here!)
\RBBS\UTILS (Or here!)
7. [ ] Copy RBBS-PC.EXE to the current directory (C:\RBBS should be).
RBBS-PC CPC17-2A Page 53
8. [ ] Copy CONFIG.EXE to the current directory.
9. [ ] Copy all MENU and HELP files to the current directory.
10. [ ] Create a text file which will serve as your bulletins menu (default
= BULLET) using your text editor. Normally, it is desirable for this to be
a single 23-line page or shorter. This is to serve as a 'menu' for the
user to select bulletins for reading by choosing a number (1-99). Each
bulletin file you create will be named BULLETxx where xx = the number on
this menu file. The following illustrates what you might create:
+-------------------------------------------------+
| Bulletin Menu |
|-------------------------------------------------|
| # | UPDATED | SUBJECT |
|-------------------------------------------------|
| 1 | 01/01/80 | TOPIC OF BULLETIN #1 (BULLET1) |
| 2 | 01/01/80 | TOPIC OF BULLETIN #2 (BULLET2) |
| 3 | 01/01/80 | TOPIC OF BULLETIN #3 (BULLET3) |
+-------------------------------------------------+
11. [ ] Create a text file for each bulletin that are going to be available
BULLET1 BULLET2 ... etc. making certain that the contents of each
corresponds to the indication in the bulletin menu file.
12. [ ] To support all of the graphics options of RBBS-PC you will need a
separate BULLET file (BULLETG for IBM-ASCII and BULLETC for ANSI
graphics). This naming convention (suffix of G or C) applies also to the
menus and the directory files. If disk space is, or is anticipated to be,
a problem use of only one set of menus. Graphics or color menus and
bulletins are entirely optional and RBBS-PC will run fine without them.
13. [ ] Create a text file named PRELOG. Although this file is truly an
an option, it is a good place for announcements which you want all
callers to see. If your system restricts new users to 1200 baud or higher
it is also a good place to let 300 baud callers know why they cannot log
on.
14. [ ] Create a text file named WELCOME (WELCOMEG, WELCOMEC, if desired)
which can contain anything you'd like to express to your callers in the way
of a greeting or other info. Many SYSOPs use this file to display their
'logo' and a brief description of the equipment they are using.
15. [ ] Now we come to the text files for the RBBS-PC file subsystem. At
this point we will use the "multiple directory" format described in
section 13 rather than the "single directory" format. These are the most
hassle, both to create initially and to maintain. The list(s) of files
are called "directories" in the documentation and should NOT be confused
with DOS "subdirectories". These text files require a very specific format
(see section 13.4) because RBBS-PC searches for information based on the
fields being pre-determined lengths.
16. [ ] You will want a ".DIR" file to correspond to each of the DOS sub-
directories available to your users for downloading.
17. [ ] Create a text file named DIR.DIR which contains a list of the
available .DIR filenames (minus the extension) and some brief description
of how the user may view these lists (i.e. L;XYZ or L;123). Now for some
RBBS-PC CPC17-2A Page 54
suggestions:
1) Place all your .DIR files in the same subdirectory.
2) If you don't want your upload directory seen, do NOT
place it in with the other .DIR files.
18. [ ] Create a text file named FILESEC which is one of the most
significant of the SYSOP generated files since it gives you total control
of which files & sub-directories are available to you or your users for
downloading. Files may additionally be protected from downloading by
password(s) which RBBS-PC will require of the user if the file is
requested. The format of this file is VERY specific as are the other
security related files you will create. See section 16.4 for a description
of the format of this file.
19. [ ] Create yet another text file named TRASHCAN which is checked by
RBBS-PC when a newuser logs on, it will contain a list of the user names
which you will not permit on your system. These might include sexually
oriented or derogatory terms, computer jargon, common abbreviations, etc.
See section 11.5 for a more detailed description of the format of this
file.
20. [ ] Create a text file named PASSWRDS from which you may control the
logon duration of various user security levels and/or permit extending the
current logon of a user through knowledge of specific passwords. Again,
the format of this file is critical to its functionality. See section
16.3 for a more detailed description of the format of this file.
21. [ ] There is one more text file which you may wish to utilize. Named
NEWUSER it is shown only to those persons signing on to your system for the
first time. It can contain anything which you want a newuser to know about
the system (ground rules,conferences, etc.). It is displayed immediately
prior to the caller being asked to C)hange his logon data, D)isconnect, or
R)egister on the system.
22. [ ] Create a batch file to automatically bring up RBBS-PC. Typically,
this would be invoked from the AUTOEXEC.BAT file on a PC that was
primarily dedicated to running RBBS-PC. See section 14 for a more
detailed description of a suggested RBBS.BAT file.
23. [ ] Now with documentation in hand type CONFIG and press Enter. After
a welcoming screen is displayed you will be asked if you will be running
multiple nodes - for this discussion it is assumed that you have only one
phone line. So type NO and press the Enter key. In a few seconds you will
see the main configuration menu. You may now choose to have CONFIG guide
you through the critical parameters (i.e. those that typically are unique
to each RBBS-PC) or press the F1 key to access the first 'page' of the
setup options. CAREFULLY answer each of the questions regarding SYSOP
names, etc. If you are unsure of how to respond - refer to section 11 of
the documentation.
24. [ ] Check that your modem's configuration switches have been set to the
positions indicated in the docs (for Hayes 1200 external UUDDDUUD) or to
the corresponding functions as listed in the documentation for your
"Hayes-compatible" modem. This step can be tricky if your modem is not
among those detailed in the documentation - even with the modem manual in
hand. But you knew this when you saved all that money by purchasing a
non-Hayes modem.
25. [ ] Press the 'End' key, respond 'YES' at the prompt and press Enter.
RBBS-PC CPC17-2A Page 55
This creates a file named RBBS-PC.DEF in the current directory.
During the execution of CONFIG.EXE it will have also created two additional
files (one for the user file and one for the message file) using the names
you specified, or USERS and MESSAGES if you accepted the defaults.
26. [ ] Turn on your modem if external.
27. [ ] Look at your CONFIG.SYS and AUTOEXEC.BAT files and eliminate any
terminate and stay resident software.
28. [ ] Make sure you are running with IBM's (not Microsoft's) PC DOS.
29. [ ] Type RBBS and press Enter. You're on your way as a SYSOP!
RBBS-PC CPC17-2A Page 56
7. COMMON PROBLEMS ENCOUNTERED INSTALLING RBBS-PC
--------------------------------------------------
IT CONTINUALLY RECYCLES! This can have several causes. RBBS-PC requires
that a modem be attached to your communications port. Therefore:
1.) check what communication port is being used.
2.) verify that the communications port exists.
3.) verify that your modem is attached to it.
4.) verify that your modem is powered up.
5.) verify that your modem is configured properly.
6.) verify that CONFIG is configured for your modem.
7.) verify that the modem cable supports all ten signals required by
RBBS-PC (see Appendix S).
8.) verify that DTR is set to "normal" rather than always "on" (i.e.
true).
9.) verify that each DOS subdirectory referred to in CONFIG exists.
10.) verify that RBBS-PC run properly when CONFIGured for COM0 (i.e.
a local workstation).
If, after all of the above has been attempted, the problem still persists,
try deleting your MESSAGES and USERS files and re-run CONFIG to create new
ones.
Finally, having exhausted all the above remedies, the system continues to
continually re-cycle, you may have an incompatible "clone" PC, incompatible
DOS, incompatible modem, and/or a bad copy of RBBS-PC.EXE.
IT WON'T ANSWER THE PHONE! This also can be caused by one of the following
things:
1.) Phone line is not plugged into the modem.
2.) Modem is not powered on.
3.) Modem is not connected to the communications port that RBBS-PC was
told to use.
4.) Your modem is not "Hayes compatible" enough to handle the modem
commands described in section 12.
5.) Your modem cable does not have PIN 22 connected.
RBBS-PC does not require PIN 22 to be hooked up on the RS-232 cable
(that's the cable which runs between the modem and the computer) if you
specify in CONFIG that RBBS-PC is to answer the phone on zero rings
(and that it is not a RING-BACK system). In this setting RBBS- PC will
initialize the modem so that the MODEM automatically answers the phone.
RBBS-PC's default is that RBBS-PC depends on either PIN 22 (i.e. "ring
indicator") or the modem sending the characters "RING" to know when the
phone is ringing. This is because RBBS-PC, and NOT the modem, answers the
phone by issuing the ATS1? command to determine what ring has occurred and
then the ATA command to tell the modem to answer the phone (see section
12). If your modem does not send the characters "RING" each time the phone
rings, then you will need a cable with PIN 22 connected. Some computers
(i.e. the PCjr's external RS-232 interface) and some modem cables don't
have a "ring-indicator" signal. PIN 22 is the ring indicator coming
from the modem going to the computer. Just because you bought an RS-232
cable, don't assume that it has PIN 22 connected. The $55 12-pin RS-232
cable sold by many computer stores often may not have PIN 22 connected.
For about $18 in parts from Radio Shack you can put together your own
RS-232 cable with all the pins connected. A friend of mine paid $14.88
(including postage) for a RS- 232 cable with all the pins connected by
ordering part number CDB25P-4-S from Jameco Electronics. Jameco
Electronics' telephone number is (415) 592-8097.
RBBS-PC CPC17-2A Page 57
There have been numerous revisions of the ROM in the Hayes modems. If all
else fails, you might try adjusting the number of rings that RBBS-PC is to
wait until it answers the phone (CONFIG parameter 204). If it won't answer
on one ring, set it to 0. If it won't answer on zero rings, set it to one.
IT LOCKS UP MY SYSTEM! Actually this is probably caused by one of the
following things:
1.) The .EXE file generated by the BASIC compiler is incompatible
with either the DOS that you are running (i.e. it isn't IBM's
DOS) or the other software you load into the system prior to
running RBBS-PC via CONFIG.SYS or your AUTOEXEC.BAT file.
2.) You indicated in CONFIG that you were running in one of the
supported networks (i.e. CORVUS, MultiLink, Orchid, etc.) but you
aren't.
3.) You are running on a Compaq Deskpro (or using an add-on board
that uses the unused IBM DOS interrupt X'7F') and should have
used CONFIG parameter 29 to indicate you are using a Compaq PC.
4.) You are using an internal modem that doesn't have the same switch
settings as the Hayes 1200 and/or your modem needs to have the
result codes turned off when RBBS-PC re-cycles. Set the modem
initialization string to "ATQ1E1F1M1X0H0".
RBBS-PC CPC17-2A Page 58
8. PLANNING YOUR USER INTERFACE
---------------------------------
RBBS-PC provides each SYSOP the maximum control over what is presented to
callers. There are three areas of control:
1. The menus presented to novice callers.
2. What is included in the prompt all users get.
3. What symbol invokes a particular function.
8.1 Menus Shown to Callers
--------------------------
The menus in RBBS-PC are external text files that are presented to novice
users. RBBS-PC simply displays what is in these files to the callers.
Therefore, SYSOPs are free to change the text in these files to whatever
they desire. Simply edit the files. However, be sure to use an editor
that produces only ASCII text files with no special embedded characters.
Most word processing editors are not suitable because they insert special
symbols in the file meaningful only to it. WordStar, in non-document mode,
is fine, as is the Personal Editor when files are saved with no tabs, and
the Program Editor. Most editors used for creating computer programs are
suitable.
RBBS-PC supports three types of files, which the caller can select using
his graphics preference. A file with no graphics has only typeable text.
ASCII graphics means that all 255 ASCII values display on the caller's
screen using the IBM PC display conventions. This allows support for many
symbols, such as straight lines, a heart, and many others. Using these
conventions, many fancy graphic displays are possible. Last, a use can
request color graphics, which means that the caller's monitor supports not
only the IBM display conventions but supports ANSI commands for controlling
the monitor, which include such things as color as well as special modes
like blinking. Using ANSI commands, it is possible to fully control the
caller's monitor. One can go so far as to create animated pictures.
Menu files are known by their names. The format is XXXXXXXY, where XXXXXXX
is the base file name and Y is a one-character addition. Y is nothing for
no graphics, G for ASCII graphics, and C for color graphics. RBBS-PC will
look for a file based on the users graphic preference and display the
graphics version if it exists. Otherwise, the non-graphics file is used.
Graphics files have more characters in them and therefore take longer to
transmit. Creating them is not easy. However, there are special ANSI and
graphics editors which make creating such files much easier.
RBBS-PC CPC17-2A Page 59
8.2 Subsystem Prompts Shown to Callers
--------------------------------------
RBBS-PC has several configuration options which allow each SYSOP to select
the prompts that are presented to callers. They are:
1. Whether the section name is shown.
2. Whether the letters of the available commands are shown.
The commands in RBBS-PC are divided into four sections: MAIN, FILE,
UTILITY and LIBRARY. Each has a set of commands in them and there are
commands to move between sections. If the SYSOP elects for the section
name to be shown, the command line will read "<section> command", otherwise
"Your command". The default is to show the section.
RBBS-PC normally prompts a caller with the commands available in each
section that the caller has sufficient security to invoke. Each command is
a single letter and is shown separated from the others by a comma. These
command letters can either be suppressed or not. By leaving them on a
SYSOP provides each caller with a terse but helpful reminder of what
commands are available to them.
RBBS-PC CPC17-2A Page 60
8.3 Commands Available to Callers
---------------------------------
All primary commands in RBBS-PC are invoked by single letter commands. An
attempt is made to associate the command with the first letter in a word
which describes the function, so that the command letter appears to be a
short abbreviation for the longer word. The command to invoke reading
messages is R. The default symbols that would be shown in the command line
for each section are:
section|? @ A B C D E F G H I J K L M N O P Q R S T U V W X Y 1 2 3 4 5 6 7
-------|-------------------------------------------------------------------
MAIN |? @ A B C D E F H I J K O P Q R S T V W X 1 2 3 4 5 6 7
|
FILE |? D G H L N P Q S U V X
|
UTILITY|? B C E F G H L M P Q R S T U X
|
LIBRARY|? A C D G H L Q S V X
|
GLOBAL |? H Q X
Four commands, ? H Q and X, have the same meaning in every section and are
known as "global." The other commands all have unique function specific
for the section within which they are invoked. For example, S in the main
section stands for S)can messages, but S)ubstring search in files &
Library, and S)tatistics on the board and session in utilities. Symbols 1-
7 stand for SYSOP functions.
RBBS-PC allows the SYSOP to substitute any symbol for any command. Y)ell
may be substituted for O)perator page, or Y)our mail for P)ersonal mail.
If a blank is substituted, the command is removed from the list and is no
longer available. Since there is no V)iew conference command in the main
section, a SYSOP may elect to disable the V)iew conference command in the
main section by substituting a blank for it.
RBBS-PC CPC17-2A Page 61
8.4 RBBS-PC's "Wrap-around" Command Search
------------------------------------------
There is a special option available in CONFIG which gives the SYSOP unusual
flexibility in configuring the user interface. A caller is always "in" a
section, that is where RBBS-PC looks for a command that the user requests
to see whether it is a valid command. The "wrap around" option controls
how RBBS-PC looks further for a command when it is not found in the section
the caller is in. If a SYSOP substitutes a blank for the V>iew conference
command in the main section (as mentioned in section 9.3) and a user enters
the V command from the main section, the V>erbose ARC file list command
would be what the caller would have invoked.
The fundamental idea is to look further in other sections, where the search
order is MAIN->FILE->UTILITY->LIBRARY->GLOBAL->SYSOP and the search is
circular, more like
,-->- SYSOP --> MAIN -->---.
| |
| |
GLOBAL FILE
| |
| |
`-<- LIBRARY -<- UTILITY <-'
The current section determines only where the search starts. If roll-
around is used, the search will go completely around. The real reason that
"global" commands are global is that RBBS-PC always searches after the
library section if a command is not in the current section. SYSOP commands
are therefore global for the same reason.
The important feature that roll-around supports is that a command with a
unique letter works in all sections. Thus W)ho will work everywhere the
same if roll-around is enabled. THIS ALLOWS THE SYSOP TO SUPPRESS
SECTIONS. In effect, by enabling roll-around and giving each command a
unique symbol, all commands become global and there is no effective
difference between sections. This allows SYSOPs to make commands available
on a single level and makes it unnecessary to "go" to a section before
using a command in that section.
RBBS-PC CPC17-2A Page 62
8.5 How to Have a Single Universal Command Line
------------------------------------------------
The command structure within RBBS-PC can be made "flatter" without making
it absolutely flat. Suppose, for example, that a SYSOP wants callers to be
able to do all file functions without going to a files section. In effect,
the file functions are available in the main section, or the file section
is merged into the main section. All that is needed to do is to eliminate
the overlap in command letters between the two sections.
The main section and the file section share the letters D, P, S, and V. V
is used to "view" a conference in the main section and "view" what is
contained in an .ARCed file. D is difficult because both D)oors and
D)ownload are entrenched and natural options. One could leave D for the
most frequently used function, say download, then use a special but
arbitrary symbol like # for doors. Similarly, V could be left for viewing
conference mail in the main section and a special but arbitrary symbol like
& for viewing .ARCed files in the file section.
S)earch for substrings could be replaced by F)ind since F for going to
F)iles is not longer needed. This could be accomplished by disabling
F)iles and substituting F for S in the files commands. The main
disadvantage is that experienced users will use F expecting to get into the
F)iles section and will get a confusing command. Alienating the old users
who will try to use F would defeat the purpose of helping them by making it
unnecessary to use F to get the file functions. Better to leave F alone
and use a new letter like Z for Z)ippy search.
P is used for personal mail in the main section as well as personal files
in the file section. Leaving P in the main section for personal mail and
selecting the special (but arbitrary) symbol * for personal mail in the
file section would have the lease impact on callers.
U has to be upload. Note that Quit could still get one to utilities.
Using Q;U we can then disable U in the main menu. If three symbols is too
much of an exception we could use W for W)rite user preferences and use the
special, but arbitrary, symbol % to find who else is on. Then we could
revise the main menu to read
R B B S M A I N M E N U
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- MESSAGES -- -- SYSTEM -- - FILES - - UTILITIES - - ELSEWHERE
-
[E]nter Message [A]nswer survey [D]ownload [H]elp (or ?) [Q]uit
[K]ill Message [B]ulletins [L]ist [%]Who's on [F]iles (Q;F)
[P]ersonal Mail [C]omment [N]ew [X]pert on/off [G]oodbye (Q;S)
[R]ead Messages [#]DOORS [*]Personal files [W]rite user
[S]can Msg header [I]nitial Wel [U]pload preferences
[T]opic msg scan [J]oin a conf. [&]View ARC files (Q;U)
[V]iew mail wait [O]perator Page [Z]ippy search [@]Library
RBBS-PC CPC17-2A Page 63
This menu could be re-written without any apparent sub-sections (by using
the letter F to find who else is on) as
R B B S M A I N M E N U
~~~~~~~~~~~~~~~~~~~~~~~~~~~
[A]nswer survey [H]elp (or ?) [P]ersonal mail [U]pload a file
[B]ulletins [I]nitial welcome [*]Personal files [V]iew conference mail
[C]omments [J]oin conference [P]ersonal mail [&]View ARC files
[#]DOORS [K]ill message [Q]uit [W]rite user's
preferences
[D]ownload [L]ist files [R]ead messages [X]pert on/off
[E]nter msg [N]ew files [S]can messages [Z]ippy search
[F]ind who's on [O]perator page [T]opic msg scan [@]Library
[G]oodby
Obviously the limitations of using a single section (as the more primitive
bulletin board systems do) means that the number of commands must be
restricted to either
a.) 26 (letters in the alphabet), or
b.) 36 (letters in the alphabet plus the numbers 0 through 9), or
c.) full "words".
With this artificial limitation of a single section, commands become
limited in number, cryptic, or both. If the even more clumsy use of full
"words" is chosen, the system must slow down as it can no longer act
immediately upon seeing the first character of a command as RBBS-PC does.
However, assuming that someone would actually wanted to configure RBBS-PC
to be "flat" (i.e. have a single command line), let us continue. In order
not to confuse the caller by being in a section and seeing only some of the
commands we want him to use, the SYSOP could elect not to show the section
in the prompt (CONFIG parameter 37) and not to show the commands (CONFIG
parameter 38). Callers would see simply "Your command?" as the prompt.
This makes the expert mode pretty terse, but that simply means users would
spend more time in novice mode before using expert.
Now suppose that only a single command line was desired and that the
commands from the "Utilities" menu commands were to be added to the above.
The "global" H, ?, Q, and X commands already are in the single command
line.
M for message margin can remain unchanged since it is unique to the
Utilities subsystem.
In order to accommodate the redundancy of letters that exist by including
the Utilities subsystem's commands, the W command for the main message
subsystem can be re-enabled and the remote SYSOPs commands be eliminated in
order to re-use the numbers. The Utilities subsystem commands B, C, F, G,
L, R, and S could then be replaced by the numbers 1 through 9. The
Utilities subsystem commands T, U, E, and P could be replaced by the
commands <, >, \, and /, respectively.
RBBS-PC CPC17-2A Page 64
This final menu of all RBBS-PC commands could be re-written without any
apparent sub-sections as follows and the screen that the would appear to
the "novice" users as:
R B B S C O M M A N D S
~~~~~~~~~~~~~~~~~~~~~~~~
[A]nswer survey [O]perator page [1] Change Baud Rate 300-->450
[B]ulletins [*]Personal files [2] Display time of day
[C]omments [P]ersonal mail [3] Set file transfer protocol
[#]DOORS [Q]uit [4] Set type of graphics mode
[D]ownload [R]ead messages [5] Set page length
[E]nter msg [S]can messages [8] Review callers preferences
[G]oodbye [T]opic msg scan [9] Display system statistics
[H]elp (or ?) [U]pload a file [<] Toggle users options on/off
[I]nitial welcome [V]iew conference mail [>] Show the log of callers
[J]oin conference [&]View ARC files [@] Library
[K]ill message [W]ho's on other nodes [\] Change echo selection
[L]ist files [X]pert on/off [/] Change password
[M]argin set [Z]ippy search
[N]ew files
Your command?
RBBS-PC CPC17-2A Page 65
8.6 RBBS-PC'S Programmable User Interface (PUI)
-----------------------------------------------
The programmable user interface (PUI) lets the SYSOP take TOTAL CONTROL
what the caller is presented with, including
o the novice menu
o the prompt line
o the organization of commands into groups (sections)
o the flow between sections
o unlimited levels of nested menus.
This allows RBBS-PC interface that the caller sees to take on any
appearance desired by the SYSOP. In effect, the SYSOP is limited only by
the intrinsic functions of RBBS-PC that have been programmed into the RBBS-
PC BASIC source code.
These functions can be assigned any command letter desired in the
configuration program. PUI lets the SYSOP completely control how these
commands are presented to the user - allowing RBBS-PC to "emulate"
virtually any other host communications environment that the SYSOP's
callers may be familiar with.
If no PUI is provided, RBBS-PC defaults to dividing the commands into a
MAIN, FILES, UTILITIES, and LIBRARY section.
RBBS-PC's PUI gives each SYSOP the flexibility to tailor RBBS-PC to meet
special needs. In effect, RBBS-PC's PUI allows the SYSOP to adjust RBBS-PC
to what the SYSOP wants, rather than forcing the SYSOP and his callers to
conform to RBBS-PC.
However, unlike RBBS-PC, the PUI does not adjust the prompt to show only
the commands that the user's security level makes him/her eligible for.
And, of course, PUI takes much more time to design and implement.
When the SYSOP takes control of what the user is presented by using the
PUI, RBBS-PC does what the SYSOP has explicitly set up -- and nothing else!
For example, RBBS-PC's "global" commands, like help and the expert toggle,
are no longer automatically available everywhere. They are available only
where the SYSOP has indicated via the PUI.
RBBS-PC's default user interface has evolved over the years to represent
what the callers found useful (not the SYSOPs!). A great deal of time and
thought went into RBBS-PC's default user interface, and it is easy to
overlook important things when a SYSOP goes about setting up his or her
own. When using the PUI assume that a new user interface will take time to
both develop and refine (based on your callers feedback). Designing and
implementing a PUI is not a simple undertaking as it is a total replacement
for RBBS-PC's standard user interface.
RBBS-PC CPC17-2A Page 66
8.6.1 An Example Using PUI
--------------------------
The main menu in RBBS-PC can represent a bewildering variety of commands,
especially to a new user. Psychologists often say that human beings can
effectively deal with only at most 7 choices at one time, whereas RBBS-PC
has 17 in its main section. To help people out in this situation, the
different choices in RBBS-PC are grouped into related commands, but the
choices can still be overwhelming. Some SYSOPs have therefore wanted to
simplify the main menu by breaking it up into more sections. The most
tempting group of commands to spin off are the message commands. Suppose
the main menu is to be simplified to look like:
<F>iles
<M>ail
<U>ser preferences
<G>oodbye
The <M>ail command in turn puts one in a section where commands pertinent
to messages become available in yet another menu, such as J)oin and E)nter.
PUI is required because the commands are grouped into different sections.
While the default menu of RBBS-PC could be edited to say this, the
underlying commands would not be grouped as desired.
RBBS-PC CPC17-2A Page 67
8.6.2 How to Implement PUI
--------------------------
First, plan carefully on paper exactly what you want the caller to see and
what happens with each command. Consider also, if you have a submenu, how
users are to get out of it.
Each menu or section of PUI is controlled by a file whose extension is
"PUI". The PUI is installed by putting a "main" PUI file whose name is
specified in the configuration program. The default is "MAIN.PUI". Each
sub-board in RBBS-PC can have a different PUI system if desired. A PUI
file consists of exactly 10 lines, and the format is:
line 1: <name of novice menu>
line 2: <prompt to display>
line 3: <valid commands>,<corresponding RBBS-PC commands>
line 4: <which valid commands are menus>
line 5: <names of PUI's that are menus>
line 6: <letter of quit command>
line 7: <prompt for quit command>
line 8: <valid sub-commands of quit command>
line 9: <which quit commands are PUI's>
line 10: <names of menu PUI's in quit command>
The text in the lines should NOT be enclosed in quotes, except possibly the
two parts of line 3.
The novice menu is just a text file displayed to novices, just like the
default menus (MENU1, MENU2, etc.). The name can include a drive or path
as well as an extension. The menu PUI's in lines 5 and 10 must be stored
in the same drive/path as that in line 1.
The prompt to display is what all callers see when asked for a choice,
including experts. Normally this includes a brief listing of the commands
available along with a request for a command. This prompt is NOT
dynamically adjusted to reflect the security level of the caller, unless
the default prompt in RBBS-PC, which removes commands the caller cannot
execute.
Each PUI defines a "section" of RBBS-PC (just like RBBS-PC has a default
section of main, file, library, and utilities). The valid commands are the
symbols for the acceptable commands in this PUI section. They must be
upper case only. The first part is the names of the commands that the
caller must give. Each symbol must be mapped to a corresponding internal
symbol name in RBBS-PC which is set in CONFIG. This way the same letter in
a given menu can be used for different commands in RBBS-PC, just as "S"
stands for S)can messages in the main section and S)ubstring search in the
files section. Since the default underlying RBBS-PC commands use the same
letter in different menus, you should first reconfigure RBBS-PC to assign
each RBBS-PC command a different underlying symbol. Then in the PUI file
map the letter you want the caller to use to that underlying symbol. Be
sure in configuration NOT to limit commands to the current section -- you
must let RBBS-PC search in other sections for underlying commands when it
does not find it in the current section.
In addition to the normal commands available in RBBS-PC, the SYSOP can
include new commands which invoke other menus. These must be symbols in
the list of valid commands.
If a valid menu choice is picked, there must be a PUI file for that choice.
Line 5 tells what prefix the PUI file has. Each PUI name must consist of
RBBS-PC CPC17-2A Page 68
exactly 7 positions. The PUI name can be shorter than 7 letters, but in
the list you must blank fill out to 7 positions to the right. The first 7
characters are for the first valid menu command, the second 7 characters
are for the second valid menu command, etc. RBBS-PC will automatically
append the extension "PUI" to this file name. The file name can include
trailing spaces, and must if shorter than 7 characters (any blanks in the
name will be omitted). Note that all PUI files must be in same drive/path
as the novice menu in line 1.
The last 5 lines in the PUI file concern how control goes from one PUI to
another. The PUI processing supports a "quit to" command in which the
caller can jump to other menus - which one is specified in the subcommands
to the quit command (just like RBBS-PC's "quit" to command).
Line 6 is the symbol (in the valid commands) which is the quit-to command.
It must be a single capital letter.
Line 7 is the prompt for the quit-to command, to be presented to callers
after they select the quit-to command (type ahead is supported).
Line 8 is the list of the valid sub-commands of the quit-to command. Each
command must be a capital letter.
Line 9 tells which of the valid subcommands are pui commands. If a sub-
command is valid but not a PUI command, control will be passed to RBBS-PC
to process the quit-to command. For example, Quit-to S)ystem for hanging
up would have to be processed this way.
Line 10 tells what are the names of the PUI files for each PUI command in
line 9. The format of the PUI names is exactly the same as in line 5 -- 7
characters blank filled to the right if shorter.
The following file MAIN.PUI installs the example that was discussed in the
previous section:
MMENU
Enter choice: <F,M,U,G>
FGMU," G "
FMU
FMENU MAILM UMENU
<blank line>
<blank line>
<blank line>
<blank line>
<blank line>
The name of the menu to be displayed initially is MMENU. The prompt users
will see is "Enter choice: <F,M,U,G>?" (RBBS-PC adds the trailing "?" for
prompts). The four valid commands are F, G, M, and U. Three of these
commands invoke other menus (F, M, and U), and G is a non-menu command,
i.e. one of the base RBBS-PC functions. The PUI file name for "F" is
FMENU.PUI, MAILM.PUI for "M", and UMENU.PUI for "U". Each of these PUI
files gives the same type of information as the main PUI. For example,
MAILM.PUI might contain
MAILM.MNU
Enter choice: <E,J,P,Q,R,S,T>
EJPQRST
Q
MAIN
RBBS-PC CPC17-2A Page 69
The novice menu for the mail section is in file MAILM.MNU. This file might
contain the following text:
M A I L S U B S Y S T E M
~~~~~~~~~~~~~~~~~~~~~~~~~~~
E)nter a message
J)oin a new message base
P)ersonal mail (review)
Q)uit to main section
R)ead messages
S)can msg headers
T)opic msg scan
The prompt will appear immediately below this line unless an extra blank
line is included in the menu file. There is only one menu command: Q for
getting back to the main menu.
The PUI system can also be used to emulate the default RBBS-PC commands
with 4 sections. Four sample files are provided for accomplishing this:
XMAIN.PUI, XFILE.PUI, XUTIL.PUI, and XLIBR.PUI. For novice menus, each
uses the standard default menu that comes with RBBS-PC. These presuppose
that RBBS-PC has been configured with the following symbols for the
underlying RBBS-PC commands:
MAIN = normal: ABCDEFIJKOPRSTUVW
reconfigured: ABC>EFIJKOPRSTU\W
FILES = normal: DGLNPSUV
reconfigured: DGLNYZ^V
UTILITY = normal: BCEFGLMPRSTU
reconfigured: !#E$<&M*()-+
GLOBAL = normal: H?QX
reconfigured: H?QX
SYSOP = normal: 1234567
reconfigured: 1234567
LIBRARY = normal: ACDGLSV
reconfigured: []{G}:'
RBBS-PC CPC17-2A Page 70
8.7 RBBS-PC's Support of Sub-menus
----------------------------------
Sub-menu support means that an item on a menu can itself be another menu,
so that selecting it results in a new menu being displayed from which the
caller can select yet another option.
The areas in RBBS-PC that can have sub-menu support include: answering
surveys, bulletins, doors, joining a conference, and the file subsystem
command to list directories.
A primary use of sub-menus is to simplify the user interface, chiefly by
allowing sub-categorization of the option. For example, suppose a SYSOP
has a complex system of doors, including multi-user games (TREK, NAPOLEON,
3DCHESS), single-user games (D&D, R&R, PICKUP), and demonstrations (DBIII,
ORACLE, ADVENT). These could be presented on a single menu, such as
The following Doors are available:
Multi-User Games
TREK - explore the galaxy, compete with 12 other players
NAPOLEON - be Russia, Italy, or England and fight the computer
3DCHESS - are you ready, Spock?
Single-User Games
D&D - the Unix dungeons and dragons!
R&R - welcome to Taipei, Tokoyo, or Bangkok, soldier!
PICKUP - do you have what it takes?
Demos - all self running
DBIII - Special version of DB3 adopted for remote usage
ORACLE - see the power of SQL. Full screen if you emulate ANSI.
ADVENT - our own home brewed ...
With sub-menus, the user could see a single, 3 item menu
Doors are available for:
MGAME - multi-user games
SGAME - single-user games
DEMO - self running demos
When the caller picks one of these three, a new menu comes up that lists
the particular doors for each category. For example, after picking MGAME
the caller sees
Multi-User Games available include:
TREK - explore the galaxy, compete with 12 other players
NAPOLEON - be Russia, Italy, or England and fight the computer
3DCHESS - are you ready, Spock?
RBBS-PC's sub-menu capabilities allow SYSOPs to set up "tree-structured",
"key word" paths to options. Bulletins provide an example where this type
of structure can be very useful. Bulletins have two main uses: short,
system-wide announcements, and a standard stock of text files for policies
and procedures for a RBBS-PC. Some SYSOPs, however, have wanted to put up
an elaborate system of announcements, where in fact these "bulletins" are a
featured way of presenting data to callers. For example, an association
published 300 short pamphlets under a dozen categories, and wants to make
this information available on-line. Sub-menus fit this need very well.
The top bulletin menu could read
RBBS-PC CPC17-2A Page 71
Bulletins are available for:
NURSES - nurses
OB - obstetricians
PED - pediatricians
FAM - family physicians
Please type in the category you want:
OBS, instead of being a bulletin, is a sub-menu that displays:
The following bulletins are available for OBSTETRICIANS
Each entry shows the length and price per glossy copy.
NAT - natural childbirth, 8 pages, $3
MIDW - midwives. 20 p., $5
NUTRI - special nutritional needs of pregnant women, 25p, $6
FPLAN - family planning services, 40 p, $3
DRUG - drugs to beware when pregnant, 50 p., $5
When the caller picks MIDW, the associated document is displayed.
Bulletins become a menu-driven way of selecting documents to browse.
There are four general changes to the commands when utilizing RBBS-PC's
"sub-menu" features.
First, to get the menu displayed when in expert mode, the caller selects
the L)ist function.
Second, the menu processing routine will search for a file associated with
the option selected. Bulletins and file directories will be displayed to
the user. These are essentially "display" functions. If a conference
exist with the name specified, RBBS-PC will attempt to join it. If a door
exists AND it is on the menu, RBBS-PC will attempt to invoke it. This
means that the option does not have to be listed explicitly in the menu.
Options can be hidden from the user and still work (except for doors). A
"secret" conference can be available only if the caller already knows the
name.
Third, the prompt is more standardized.
Fourth, the standard way to get out of the menu is just to press [ENTER].
The bulletins function has been generalized so that bulletins can use names
and not just numbers. For example, selecting "B" as the bulletin prefix,
the above bulletins would be files BNAT, BMIDW, BNUTRI, BFLAN, and BDRUG.
However, the search for new bulletins works properly only if numbers are
used to name bulletins, and the prompt for bulletins simply asks for the
bulletin and does not mention any numbers.
RBBS-PC CPC17-2A Page 72
8.7.1 How to Implement Sub-menus
--------------------------------
If "XXX" is an option on a menu, simply create a file named "XXX.MNU" that
has in it the text for the menu. Put this file in the same drive/path as
the non-menu options (e.g. where the "BAT" files go for doors, where the
bulletin files to display are put, where the directory files are). For
example, if "B" is the bulletin prefix, the above example would be
implemented by adding the files "BNURSE.MNU", "BOB.MNU", "BPED.MNU", and
"BFAM.MNU". Put these files on the same drive that the bulletins
themselves go.
Callers can list any menu at any time as long as the menu they wish to list
has the qualifier "MNU". For those menus that the CONFIG utility does not
allow the SYSOP to enter a qualifier, the SYSOP can use an editor to edit
the .DEF file and add a qualifier directly.
8.7.2 Shared Options Across Sub-menus
-------------------------------------
Each option on a sub-menus used to have to be uniquely named, because they
all shared the same prefix. Hence no two submenus could offer the same
option -- RBBS-PC couldn't have all menus with 1,2,... or A,B,C,... as
options to pick. RBBS-PC 17-2A supports using same response on different
menus. The way that this works is RBBS-PC now searches both for the global
prefix and the user response as well as looking for the current prefix and
user response. If the bulletin prefix is "B", and the structure of
bulletins is as follows:
/ 1 N is main bulletin menu
A ---- 2 BNA.MNU submenu get with choice A
/ \ 3 BNB.MNU submenu get with choice B
/ BNC.MNU submenu get with choice C
/ / 1
N ---- B ---- 2 BNA1, BNA2, BNA3 bulletins get under NA
\ \ 3 BNB1, BNB2, BNB3 bulletins get under NB
\ BNC1, BNC2, BNC3 bulletins get under NC
\ / 1
C ---- 2
\ 3
RBBS-PC CPC17-2A Page 73
8.8 RBBS-PC's "Macro" Command Support
--------------------------------------
RBBS-PC's "macro" support expands a single keystroke into multiple
keystrokes. It allows RBBS-PC to be tailored in even a greater variety of
ways than before because a single command can be set up to invoke a
sequence of multiple RBBS-PC commands. The concept is similar to that
pioneered by Prokey, except that in RBBS-PC the SYSOP defines the macros
and the caller invokes them transparently without knowing.
Macros are an extension of the effort in RBBS-PC to give the SYSOP control
over the user interface. RBBS-PC allows the SYSOP to substitute any
letter for any command, to group the commands in any way desired, and to
have unlimited submenus. Macros give the SYSOPs the ability to create and
mold their RBBS-PC into an unlimited variation of commands. RBBS-PC's
"macro" command facilities frees every SYSOP from having to impose the
rigid and inflexible command structure on their callers that other more
limited PC-based bulletin board systems impose.
Macros add a new dimension to RBBS-PC commands -- commands can be a full
word rather than just a single letter. A macro is invoked by a name up to
8 symbols. For example, "DOOR" and "OPEN" can be used to invoke doors.
This makes it easy to make all commands available on a single level. For
example, the otherwise irreconcilable conflict between "Download" and
"Door" can be resolved by using the full word "DOOR" for doors.
Macros can be used to abbreviate a longer series of commands. If the SYSOP
wants to use "A)bandon conference", all that need be done is to add a macro
called "A" whose content is "J M" (join main). Or if N)etmail is to be
used to read Fido-net compatible message bases, a macro called "N" could be
set up as "D NETMAIL" (use door called NETMAIL). Since doors are unlimited
in nature, RBBS-PC thus can have UNLIMITED commands.
A string of RBBS-PC commands can be stored in a macro for many different
types of purposes, including (but not limited to)
setting up demos, or
showing a user what to do rather than just explaining it in words, or
automating testing when doing RBBS-PC development, or
automating a check-out of all of the RBBS-PC functions.
Macros can also be used to make the same type of function do different
work. For example, the B)ulletin command basically displays a text file.
Suppose an association wants to let persons order pamphlets and preview
them on-line. Rather than bury the ordering function insider A)nswer
questionnaire and the preview function inside B)ulletins, the commands
PREVIEW and ORDER can be added as macros, where ORDER stands for "A
ORDWHAT" AND "ORDWHAT" is a submenu listing what all can be ordered, and
each option on the submenu is a questionnaire. PREVIEW similarly is "B
PREWHAT" where "PREWHAT" is a submenu listing the available pamphlets they
are stored as text files.
Macros can be built to provide interactive help to callers. For example,
you can put up a macro called EZDOWN to help people download. It explains
everything, asks for the file name and protocol, and tells the caller what
they should be doing on their end, and then drives the download.
Macros can be used to provide integrated data bases. Unlike
questionnaires, you can totally control how data is written to a file.
You can put in labels, or data only, put the values in quotes, separate the
values by commas, etc. This is done by writing to a file. A block of
RBBS-PC CPC17-2A Page 74
text functions like a template into which data values are substituted.
Macros can be used to give "tours" of your RBBS-PC -- to showcase new or
special features.
Macros have security levels built into them to control access, just
like regular commands.
Macros can be
1.) invoked anywhere within RBBS-PC -- including questionnaires,
2.) unlimited in length,
3.) used even when the caller has "turbo" key feature enabled,
4.) used with "Smart" Text (see section 8.9),
5.) used to store responses that can be manipulated latter, and
6.) used to support graphics versions of text.
It is important to remember that a macro will be ignored if its name is the
same as any command. To replace a command with a macro, you must insure
that the letter for the command has been reassigned. CONFIG parameter 30,
parameter 31, parameter 32, parameter 33, and parameter 34 allow such
reassignments to be easily accomplished.
The only "restriction" that exists is that the prompt for "More" and file
directories will not accept any macro with a single letter.
Macro commands with more than one letter override all others. This means
that the macro interpretation will prevail if more than one interpretation
is possible. For example, in the absence of macros the command "door"
would the interpreted as the command "d", so that saying "door" in the
files section would be download. But a "DOOR.MCR" would be executed
instead when it exists. One letter commands, however, will be executed
when they match a command letter, and so any macros will be ignored that
have the same one letter name the same as a command.
RBBS-PC CPC17-2A Page 75
8.8.1 How to Set Up "Macros"
---------------------------
The first line in a macro simply REPLACES the macro name and therefore
operates in its place. If PREVIEW is typed in and the first line is "B"
for bulletins, then "B" will replace "PREVIEW" and the command will proceed
exactly as if "B" has been typed instead of "PREVIEW".
Subsequent lines in a macro are stored in a buffer and read off as if they
were typed. Realize that in reading everything is read in a line at a
time, i.e. up to a carriage return.
Two configuration parameters must be specified: the drive/path where macro
files are stored (CONFIG parameter 79) and the extension the macro files
will have (CONFIG parameter 80). The default names are "C:" and "MCR". To
create a macro named X, simply create a file with prefix X and the macro
extension and place in it the macro drive/path.
The first line within a "macro" contains the numeric integer value which
represents the minimum security to use the macro.
The first line of a macro must be the minimum security level to use the
macro. The macro will simply be ignored if the caller has insufficient
security. The second line will be parsed and replace the macro name. The
remaining lines will be placed in the stack and will be read
in as if typed.
Macro commands have the same structure as SmartText variables:
<command prefix><command name>
where <command prefix> is the SmartText command specified in CONFIG.
The symbol "{" (ascii 123) is the default. The <command name> consists
of two characters. Lines that are not valid macro commands are simply
passed to RBBS as if the user had typed them in. There are three
differences between SmartText variables and macro commands:
(1) Macro commands must be the first three characters on a line,
whereas SmartText variables can occur anywhere on a line.
(2) Macro commands can have an argument after the command name, and
(3) A macro command can apply to a block of lines following it.
RBBS-PC CPC17-2A Page 76
8.8.2 Macro Commands
--------------------
RBBS-PC "Macro" Commands includes the capability of having commands
executed within the "macro" rather than simply passing keystrokes to RBBS-
PC. In all prompts and blocks, substitution is supported for both stored
answers SmartText variables. The macro commands include:
o display a line with no carriage return
o display a line with carriage return
o display a block of lines
o display a file
o prompt for a response and store answer
o pause a specified # of seconds
o stack keystrokes
o append a block of lines to a file.
o control whether the macro text is echoed or not
o retrieve values from a file into a form which is the displayed
Following is a list and description of valid "macro" commands:
*0 - display what follows on the line with no carriage return.
*1 - display what follows on the line with a carriage return.
*B - display what follows on subsequent lines.
*F - display the named file that follows.
nn - use text that follows as a prompt and store the result.
WT - pause for the number of seconds specified after "WT".
>> - append the following block of text to the file specified.
ST - Stack the characters immediately following the "ST".
M! - Execute the named macro that follows on the same line.
ON - Case logic for branching within macros based on stored results.
EY - Echo the text passed in macros as if keystrokes.
EN - Do not echo the macro keystrokes.
<< - Display fields from a file in a form.
*0 - display what follows on the line with no carriage return.
{*0Press any key to continue
*1 - display what follows on the line with a carriage return.
{*1{FN, I hope you enjoyed your tour of the board!
The caller's first name is substituted for the "Smart" Text variable
"{FN".
*B - display what follows on subsequent lines, each line with a carriage
return, up to the line beginning with "{END".
{*B
Macro commands have the ability to display
multiple lines. The macro command is
{*B
and it will display all lines until it encounters
one beginning with {END. Like it, {FN?
{END
The caller will seen everything between the first and last lines, with
the first name substituted into the last line displayed.
*F - display the named file that follows.
RBBS-PC CPC17-2A Page 77
{*F L:\RBBS\HELP.LST
will display the file HELP.LST.
nn - use the text that follows on the line as a prompt and store the
resultant answer in an internal working variable numbered nn. nn must
be two digits and can be 01, 02, 03, ..., 99. CONFIG parameter 94
controls the maximum # of work variables.
{01Please enter the Department you work for:
{02Please enter your Office number:
This will store the answers in work variable # 1 and 2, which can be
subsequently referenced as "[1]" and "[2]". You can have as many
work variables as specified in CONFIG parameter 94. Variables that
are reused have their values overwritten.
WT - pause for the number of seconds specified after "WT".
{WT 2
will wait for 2 seconds.
>> - append the following block of text to the file specified on this line.
{>> C:MACRO.DAT
"{FN","{LN","[1]","[2]"
{END
will append the following line to the file named MACRO.DAT on drive
C:, assuming the caller is KEN GOOSENS, and he responded to the above
prompts for Department with "Controller" and Office # with "107".
Then the line what would be written out is:
"KEN","GOOSENS","Controller","107"
As many lines can be included as desired. Simply end the block to be
written out with "{END" as the beginning of the line.
Some data base managers want fixed length files and this is possible
in the macro append. Just add "/FL" on the macro command line.
Rather than replace, the substitution will overlay the line at the
"[", thus keeping the output fixed length. Lets suppose that the
first work variable has "A" as a value, the second work variable has
the value "123456", the third work variable has "Henry" as a value,
and the caller's first name is KEN. Then
{>> C:\RBBS\DAT.FIL /FL
[1][2]....[3]...............{FN........
{END
would add the following line into DAT.FIL
A 123456.Henry.............KEN.........
Normally, blanks would be put where dots are show.
ST - Stack the characters immediately following the "ST".
RBBS-PC CPC17-2A Page 78
{ST
will stack a carriage return (no characters). And
{STD [1] [2]
would stack "D RBBS-EXE.ARC Z" - as if they were typed and ENTER
pressed - if the first work variable had "RBBS-PC.EXE" and the second
work variable held "Z". It is important to note that "macros" are so
transparent to RBBS-PC that if you use macros to display text at an
RBBS-PC prompt like "Enter command? ", RBBS-PC will continue to sit
there waiting for an answer. A stacked carriage return at the end
will cause the prompt to be redisplayed, though the effect of the
stack will vary with the particular prompt.
M! - Execute the named macro that follows on the same line. E.g.
{M! ORDER
will execute the macro called ORDER. The executes are like "go to's"
in that execution of the current macro ceases and does not return
automatically when ORDER is done. The full file name of the macro to
"go to" is not used (i.e. ORDER.MCR), only the file prefix -- ORDER.
As is shown in the example of the ON command, the macro name can have
a drive/path and/or extension. If only a prefix is put in, RBBS-PC
will automatically add the drive/path and extension for macros
specified in CONFIG parameter 79 and parameter 80. Putting in a
drive/path/extension that is different from CONFIG's assures that no
caller can invoke the macro -- it only can be used internally by your
application.
ON - Case logic for macros. This allows responses to be tested against and
branching logic developed within a "macro". An example would be:
{ON 1
=A
M! D:\HIDDEN\CHOICEA.MCR
=B
{*1You have selected option B
{02Why did you select B?
=C
M! D:\HIDDEN\CHOICEA.MCR
{END ON
EY - Echo the text passed in macros as if keystrokes. The default is to
echo.
EN - Do not echo the macro keystrokes. An example would be:
{EN
{*1 The following commands will be executed but now shown
{01 Press Enter when ready
R L
A
{EY
{*1 Same commands but now you will see the responses to the prompts
{01 Press Enter when ready
RBBS-PC CPC17-2A Page 79
R L
A
<< -Display fields from a file in a form. This is one of the most
powerful macro commands. It allows data to be stored in compact, data
format but retrieved into a form for display to a caller. There are
5 parameters that can follow the macro command:
<file name> <file format> <data#> <submode> <rec-pause>
where:
"<file name>" is the name of the data file that has records to read,
"<file format>" is "/V" if data is stored in variable length format
and "/F" if fixed length format,
"<data#>" is the number of separate fields in a record for variable
length data and the length of the data if fixed length,
"<submode>" is the mode used to substitute data in the following form
"/FL" if the form is fixed length, meaning that data is overlaid into
the form so as not to change any lengths.
"<rec-pause>" should be "/1" if you want to pause after each record
rather than when the screen fills.
An example of a "macro" that uses this capability is as follows:
{*1 -TOPIC- - DATA # - - VOICE # - -First Name- -Last Name-
{<< C:\RBBS\RHLP.DAT /V 5 /FL
[1] [2] [3] [5] [4]
{END
Note that spaces occur after the "[4]". If the file RHLP.DAT contains
"DOORS","404-981-7781","405-988-7782","Wizard","The"
"PROTOCOLS","709-123-4567","0","Horse","Crazy"
then the caller would see
-TOPIC- - DATA # - - VOICE # - -First Name- -Last Name-
DOORS 404-981-7781 405-988-7782 The Wizard
PROTOCOLS 709-123-4567 0 Crazy Horse
The same example using fixed length data would be
{*1 -TOPIC- - DATA # - - VOICE # - - Name -
{<< C:\RBBS\RFLH.DAT /F 69 /FL
[1](34:12) [1](46:12) [1](58:12) [1](1:33)
{END
where RFLH.DAT contains:
The Wizard DOORS 404-981-7781405-988-7782
Crazy Horse PROTOCOLS 709-123-45670
This would produce the following for the caller:
-TOPIC- - DATA # - - VOICE # - - Name -
RBBS-PC CPC17-2A Page 80
DOORS 404-981-7781 405-988-7782 The Wizard
PROTOCOLS 709-123-4567 0 Crazy Horse
Note that work fields support sub-field references in the format:
[n](x:y)
where n is the work field number, "x" is the beginning column, and "y" is
the # of bytes to get. If work field three had a value "123abc" then
"[3](3:3)" would have "3ab" as its value. Fixed length records are always
referenced as work variable one.
RBBS-PC CPC17-2A Page 81
8.8.3 A Sample Macro
--------------------
Suppose A)bandon conference is to be implemented in RBBS-PC. To do this,
the command A)nswer questionnaires must be assigned a different letter.
Else A will always invoke answer instead. Then the macro file could
contain
5
J M
The command "A" will then be followed by "Rejoining MAIN". Incidentally,
if the macro had been implemented by
5
J
M
The only difference is that the prompt for what conference to join will be
displayed, "M" then would be displayed as if the caller had typed it, and
then main would be rejoined. The difference is caused by the fact that the
first line after the security level is what replaces the macro name, so in
the first case "M" pre-empts the prompt but not in the second.
RBBS-PC CPC17-2A Page 82
8.8.4 On-line Data Base With Macros & Questionnaires
----------------------------------------------------
RBBS-PC provides the SYSOP with the ability to offer callers access to an
on-line database both internally (using macros and questionnaires) and
externally to RBBS-PC (see Appendix U).
RBBS-PC's internal Remote Data Base feature (RDB) gives the SYSOP the
ability to:
o set up unlimited numbers of named data bases
o set up menus to interact with the user
o prompt users for data
o use Metavariables - both work variables and SmartText variables.
o store user's answers in work variables. Any subfield in a
work variable can be referenced.
o display, or store all metavariables
o process commands conditionally
o save Metavariables to file thru templates, allowing data to
be stored in virtually any format desired
o retrieve data into templates for display.
o do full screen data entry
RBBS-PC's support for "full screen" questionnaires and macros takes some
work on the SYSOP's part. The SYSOP must use ANSI screen commands. The
SYSOP must then arrange to transmit the "template" that clears the callers
screen and writes the appropriate static text (lines, labels, etc.) on the
callers screen. Then the data the user is to see is transmitted onto the
caller's screen. The "full screen" support does not allow the caller to
use keys like tab and cursor arrows to move around on the screen. It is
"full screen" in the sense that the caller sees all the data that is to be
entered and the cursor moves from field to field.
Examples of the kind of applications that would utilize RBBS-PC's remote
data base feature are:
For Sale - ask user item, price, who to contact, telephone #. Callers can
add items, or view list of items.
BBS lists -Callers can view data base, or add BBS's where asked for name,
numbers, profile of features. No longer do BBS ads have to be left in
messages. Can have informative, standardized profile that makes BBS
comparison meaningful.
BIO - ask users for a profile of themselves so others can know who they
are.
VOTING - can collect nominations say for best GIF files. No way yet to
force a caller to vote only once.
On-line Database Example
------------------------
This application manages a data base of callers who are willing to help
with RBBS-PC by topic. It is controlled at a high level by the following
questionnaire.
C:DUMMY.DAT,4
* This questionnaire is for finding help with RBBS by topic.
* Please register yourself if you
* o are willing to help others, and
* o know enough about a topic to help
RBBS-PC CPC17-2A Page 83
*
* Examples of topics people need help with:
* Desqview Modem models (HST, Everex, USR Internal, etc.)
* PC-Slaves Protocols Conferences FMS
* Doors DoubleDos Subboards PUI
* Questionnaires 10-Net Marcos Uploads
* MU-Purge File maint. Personal dwld Caller Analysis
*
:-[prompt]-
T
? V)iew database, E)nter new data, Q)uit (V,A,Q)
=V-[view]-=E-[add]-=Q-[quit]-= -[prompt]-
:-[view]-
M C:\RBBS\VIEWHELP.MCR
>-[prompt]-
:-[quit]-
@
:-[add]-
* 703-978-6360
?1 BBS data number
* 703-978-4339
?2 Voice # (evening, 0 not to give)
* You can specify as many topics as desired, one at a time.
*
:-[topic]-
?3 RBBS topic you will help others with, or Q)uit
=Q-[prompt]-= -[addrec]-
:-[addrec]-
* -Topic- - Data # - - Voice # - Last Name First Name
*/FL[3] [1] [2] {LN {FN
T
?Really add this record (Y,N)
=Y-[really]-=N-[topic]-= -[addrec]-
:-[really]-
M C:\RBBS\ADDHELP.MCR
>-[topic]-
Two macros are used by this questionnaire:
VIEWHELP.MCR for displaying the data base, and
ADDHELP.MCR for appending new data to the data base.
VIEWHELP.MCR contains
5
{*1 -Topic- - Data # - - Voice # - Last Name First
Name
{*F RBBSHELP.DAT
{ST
ADDHELP.MCR contains
5
{>> RBBSHELP.DAT /FL
[3] [1] [2] {LN {FN
{END
{ST
Full Screen Example
RBBS-PC CPC17-2A Page 84
-------------------
Full screen is available only in a color graphics version of questionnaires
and macros. A long application for collecting BBS information is given in
these following files:
REGRBBS.DEF - Questionnaire driver, TTY version
REGRBBSC.DEF - Color graphics version of questionnaire driver
VUNRBBS.MCR - View data base macro, TTY version
VUNRBBSC.MCR - View data base macro, Color graphics version
SVRBBS.MCR - Macro to save data to a comma separated data file
These files can generally be download from most bulletin board systems.
However, they are definitely available on Ken Goosens RBBS-PC system at
(703) 978-6360.
Hints a Building Your own Remote Data Base Applications
-------------------------------------------------------
Generally you will have
o a questionnaire driver that gives caller option to exit, view
database, or Enter new data.
o a macro to retrieve data from file to a form
o a macro to save data in a data base format.
o a data entry routine in the questionnaire.
Creating a "full-screen" application is more complicated that than a line-
at-a-time (i.e. TTY) application. For full-screen applications, you will
want
o to paint a template with all everything but the data values,
such as row and column labels and titles.
o to clear out the existing values in a form and then put in
the new values.
Only the changes to the screen are transmitted rather than retransmitting
the entire screen when only a part changes.
ANSI commands are used to control the screen. Where [ESC] stands for the
one-character Escape (ascii 27), the most useful ANSI commands to know are:
[ESC][2J - clear the screen.
[ESC][K - clear from current cursor postion to end of line. Cursor
position after clearing is same as before.
[ESC][X;Yf - position the cursor on row x and column Y. E.g.
"[ESC][5;10f" positions on column 10 of row 5.
Case is significant in ANSI commands, so beware that "[ESC][k" will NOT
clear to end of line, and "[ESC][1;7F" will not position the cursor.
You can use ANSI commands to reverse the video and change blinking and set
color. An easy way consistent with RBBS-PC is to set colors using the
"Smart" Text variables C0, C1, ..., C4, where 1-4 are the colors set in
CONFIG parameter 323, parameter 324, parameter 325, and parameter 326. C0
is "emphasis off" that restores normal text color preference of the caller.
RBBS-PC CPC17-2A Page 85
An example that clears the screen, sets color to 1, positions on line 1,
column 15, prints "Sample Title-", sets color to caller's text preference,
prints 2 spaces, and then prints value of work variable 1 is as follows:
[ESC][2J{C1[ESC]1;15fSample Title-{C0 [1]
RBBS-PC CPC17-2A Page 86
8.9 RBBS-PC's "Smart" Text Files
--------------------------------
RBBS-PC's lets the SYSOP "personalize" such text files as MENUS, Bulletins,
Help, and Welcome files. This allows the SYSOP to present to each caller
an interface that is not only "programmable", as discussed in section 8.6,
but also tailored to the specific caller.
To utilize RBBS-PC's "smart" text files, CONFIG parameter 17 must be set to
the decimal value of a delineation character that the text editor used by
the SYSOP can handle. The character you select should have three
characteristics:
1.) It should be visible on the screen and when printed. This allows
the SYSOP to see where the control sequence is when designing the
text files to be used as "smart" text files.
2.) It should not be a character that might be used for any other
purpose in the text files.
3.) It should not be a character that might be interpreted, when
printed, as being a printer command (i.e. start double spacing).
Some may like to use characters created by simultaneously pressing two keys
such as the "Ctrl" and "N" keys to create a character whose decimal
representation is 14. Others may wish to use such seldom used, single
keystroke characters as:
Character Decimal
Value
@ 64
^ 94
~ 126
{ 123 <--- Default used by RBBS-PC
} 125
| 124
CONFIG parameter 17 can have any value between 0 and 255. If 0 is
selected, RBBS-PC's "smart" text capability will be turned off.
A RBBS-PC "smart" text control sequence consists of the control character
that was selected in CONFIG parameter 17 followed by a "smart" text double-
character command. These "smart" text double-character commands MUST be
entered as upper case characters! The "smart" text double-character
commands are:
COMMAND MEANING
BD Displays the bytes downloaded today.
CS Overrides RBBS-PC's automatic screen depth management so that
the next "PRESS ENTER TO CONTINUE" will not come halfway through
a page.
C0 Resets color to the user's selection for text.
C1 Changes color to the user's selection for Foreground Color One.
C2 Changes color to the user's selection for Foreground Color Two.
C3 Changes color to the user's selection for Foreground Color Three.
C4 Changes color to the user's selection for Foreground Color Four.
DB Inserts the total number of bytes ever downloaded by the caller.
DD Inserts the total number of files downloaded by the caller today.
DL Inserts the total number of files ever downloaded by the caller.
DT Inserts the current date, MM-DD-YYYY, into the text file.
FN Inserts the user's FIRST NAME (in caps) into the text file.
RBBS-PC CPC17-2A Page 87
LN Inserts the user's LAST NAME (in caps) into the text file.
NS This causes the rest of the current file to be displayed in
RBBS-PC's "none stop" mode. Page breaks will be ignored
following a NS command.
PB Causes RBBS-PC page break message, "MORE (Y/N/NS/A)" or the
"PRESS ENTER.." prompt to appear after the line is printed.
RP Inserts the number of days in the registration period.
RR Displays the days remaining in the caller's registration period.
SL Inserts the user's current security level into the text file.
TM Inserts the time (hh:mm AM/PM) into the text file.
TE Inserts the user's elapsed session time (hh:mm) into the text
file.
TR Inserts the number of minutes left in the user's session into
the text file.
UB Displays the total number of bytes ever uploaded by the user.
UL Displays the total number of file ever uploaded by the user.
When designing "smart" text files, each SYSOP should take into account that
the some of the "smart" text commands (i.e. the user's name) may
significantly extend the length of a line . It is important that this line
elongation be taken into consideration so that, when the actual text
substitution occurs, the line seen by the caller does not exceed 80
characters.
What follows is an example of a "smart" text file that demonstrates how all
of the above commands might be used. The following example assumes that
CONFIG parameter 17 has been set to the decimal value 123 for the "smart"
text delineation character -- {.
INTRODUCING SMART TEXT!
RBBS-PC allows the SYSOP to customize the text seen by each caller.
For instance, if the SYSOP wanted to make sure this message didn't
scroll off the screen, he could pause the display like this:
{PB
Or, the SYSOP may want to show the caller that today's date is {DT and
the time is {TM. The SYSOP may even want to include a personal
greeting to {FN {LN.
The SYSOP can tell the caller that their security level is {SL and
that they have been on-line for {TE, and have {TR minutes left in this
session.
This kind of capability illustrates RBBS-PC's on-going commitment to
nurturing each SYSOP's creativity and avoiding the dogmatic.
RBBS-PC CPC17-2A Page 88
8.10 "Colorizing" the RBBS-PC User Interface
--------------------------------------------
"Colorization" refers to the utilization of color within RBBS-PC text files
and prompts. RBBS-PC has long supported graphics versions of external text
files, and is even distributed with graphics menus. RBBS-PC supports
"colorization" as follows:
1.) In files shown to the callers including:
All menus,
All bulletins,
The Welcome file,
The file for new users,
All on-line help files,
Standard file directories, and
FMS file directories (see item6).
2.) Via highlighted text
in searches of messages,
in searches of files,
in announcing new personal mail waiting,
for locked out users, and
the SYSOP user maintenance (function 5).
Highlighting supports a limited but extremely functional use of
colorization - to make it easy for the caller to spot significant bits of
text on a screen.
3.) Within the Programmable user interface (PUI).
The PUI file can have graphics versions just like text files. The file
XMAIN.PUI that was used in the example in section 8.6.2 can have a
graphic's equivalent named XMAING.PUI and a color equivalent named
XMAINC.PUI. Color codes can be embedded in the prompts in the PUI as well
as external text files. Each SYSOP has total freedom to colorize prompts
as well as menus.
4.) Within text internal to RBBS-PC.
This applies to standard (non-PUI) prompts, such as the main command
prompt, and to formatted reports, like the message scan and message read.
This type of "colorization" is controlled by whether highlighting has been
turned on in CONFIG.
5.) Within RBBS-PC's "short" prompts.
Caller foreground color 4 is used to mark the commands the user can type.
Emphasis is used to mark the default selection. This colorization is based
on a scan of the text to be printed:
[...] : will be highlighted (default answer)
xxx) : will be put in foreground color 4 (text to type in): if xxx
is not longer than 2 characters and is in caps
<...> : will be put in foreground color 4 (collective choices) and
if there are words before this, 1st will use foreground 1 and
second foreground 2.
RBBS-PC CPC17-2A Page 89
"Short" prompts colorization applies to ALL text displayed by RBBS-PC
before an answer is expected. For example, by using the above conventions,
questionnaires can be colorized. This is controlled by whether
highlighting is on.
6.) Within FMS file directories.
The "colorization" of the FMS file directories is based on the four colors
specified in CONFIG and is controlled by whether or not the caller has
selected to be in color graphics mode or not.
There are two extremes on the use of color -- use none or use everywhere.
By using no colorization, RBBS-PC's performance is optimized. RBBS-PC does
not have to go through the overhead of transmitting special instructions
to control the caller's screen. The two chief functions of boards -
transmission of textual information and file exchange - do not essentially
involve the use of color. Thus "colorization" is at best dispensable and
at worse degrades the performance of these essential functions.
Of course, there are those who want their RBBS-PC's visual displays to
convey as much as the text or the files themselves (i.e. the message is in
the medium). These are the SYSOPs would elect to use color everywhere.
Color is largely used to group related information on the screen, where
everything has a color. With the use of color, plain text begins to look
drab and uninteresting and attention tends to focus on the colorized text.
For this reason, some SYSOPs find it difficult to use color in some places
and not in others.
If "colorization" is activated everywhere within RBBS-PC, it is imperative
that the PRELOG or WELCOME file inform callers to execute the G)raphics
command. RBBS-PC's default is to use "colorization" for internal prompts.
The G)raphics command ask users:
1.) If they want graphics versions of text files,
2.) Whether the caller wants prompts colorized,
3.) What color the caller wants for normal text, and
4.) Whether normal text should be bold or normal in intensity.
To Implement "colorization" within RBBS-PC, run CONFIG and go to screen 17
of the CONFIG parameters -- "RBBS-PC Color Parameters".
1.) Use CONFIG's parameter 321 to put in a string for turning EMPHASIS on.
The recommendation is a bright foreground on red background ("[27][1;41m").
2.) Use CONFIG's parameter 322 to set the string for normal text. This is
the general default color and is used to turn off emphasis. The
recommended color is amber (normal yellow) ("[27][0;33m").
3.) Use parameter 323, parameter 324, parameter 325, and parameter 326 of
CONFIG to set the four caller foreground colors. CONFIG uses natural
language phrases to set these, so it is very easy. The recommendation, in
order, is:
bright green,
bright yellow,
bright purple, and
bright cyan.
These colors are all used in the message header and general command prompt.
Foreground 4 is used to highlight the commands the caller actually needs to
RBBS-PC CPC17-2A Page 90
type in to select that option.
No colors will be displayed if these parameters are set to empty strings.
Callers can turn off the colorization simply by going into Utilities and
T)oggle H)ighlite to "off". The default in RBBS-PC is for colorization to
be OFF.
Colorization is based on the ANSI standard. Special codes are sent by
RBBS-PC to the callers system, which must then be interpreted by the
caller's communications software.
CONFIG lets the SYSOP set the strings to turn color emphasis on and off.
Inside the PUI and external text files, the SYSOP must use an editor to
create graphics files. There are special graphics editors, like THEDRAW,
or a SYSOP who knows the codes to embed can use an ordinary text editor.
RBBS-PC CPC17-2A Page 91
8.11 RBBS-PC's Automatic Operator Page Option
---------------------------------------------
RBBS-PC will "automatically page" the SYSOP whenever a specified caller or
group of callers logs on to RBBS-PC or joins a specific "conference" (i.e.
"sub-board"). The selection criteria be a specific caller's name, a range
of security levels, or whether the caller is a new user. A SYSOP may wish
to be notified for any number of reasons including:
The SYSOP wants to chat with caller or that caller has been causing
trouble on the bulletin board and needs to be monitored,
The SYSOP wants, for security reasons, to be notified when anybody
logs on with a SYSOP security level.
The SYSOP wants to chat with a friend but does not want to continually
monitor RBBS-PC's activity.
Automatic paging of the SYSOP is controlled by a file whose name is
specified in CONFIG parameter 18 (the default name is AUTOPAGE.DEF). This
file contains 4 parameters separated by commas. The format is
<condition>,<notify caller?>,<# of times>,<music>
<condition> can be a NAME enclosed in quotes, the string "NEWUSER", or a
security level range specified in the format
/<min sec>/<max sec>
where:
<min sec> is the minimum security level to include
<max sec> is the maximum security level to include
<notify caller?> is "N" if the caller is to also be notified that the SYSOP
wants to be automatically paged when the caller logs on.
Anything else means the caller will not know that the SYSOP
has been paged automatically.
<# of times> is the number of times that the PC's speaker will be
sounded.
<music> is what is to be played each time the speaker is sounded. If
nothing is specified, a beep will be used.
Examples:
"SEXY DEVIL",,3,DEL2CL4EDC means to automatically page the SYSOP when a
caller named SEXY DEVIL logs on, not to
notify the caller, and to page the SYSOP
three times playing "DEL2CL4EDC" each time.
"GREGG SNYDER",N,2, means to automatically page the SYSOP when GREGG
SNYDER logs on, to notify the caller, and to
beep the SYSOP twice.
RBBS-PC CPC17-2A Page 92
"NEWUSER",,1, means to automatically page the SYSOP when any
new caller logs on, not to notify the caller,
and to page the SYSOP once.
/10/12,N,3, means to automatically page the SYSOP when anyone
with security 10 through 12 inclusive logs
on, to let them know that the SYSOP wants to
be notified that they are on, and to beep the
SYSOP twice.
The status line at the bottom of the screen will read "Autopaged!" if RBBS-
PC has automatically paged the SYSOP. This allows the SYSOP to know that
the automatic page took place, even if the SYSOP was not present at the
beginning of the call. The following is a sample AUTOPAGE.DEF:
"SEXY DEVIL",,5,DEL2CL4EDC
"GREGG SNYDER",N,2,
"NEWUSER",,1,
"/10/12",N,3,
If more than one condition will trigger the automatic paging of the SYSOP,
the first condition encountered will be used.
Since the AUTOPAGE.DEF file can be different for each "sub-board", the
SYSOP has the option to be automatically paged based on different criteria
for each "sub-board".
RBBS-PC CPC17-2A Page 93
8.12 Enhancing the File Verbose List
------------------------------------
Within the File Subsystem of RBBS-PC the V)erbose List, sometimes called
View function, allows the caller to get a list of files that are
"libraried" inside a single file. RBBS-PC not only supports the commonly
used PKWare "zip" format, but also "arc", "pak", and "lzh", and well as ANY
library format using SYSOP-installed external procedures.
RBBS-PC assumes that the file extension will identify the type of
compression. Hence, all files with "ARC", "PAK", or "ZOO" have a different
but common compression function. RBBS-PC continues its internal support
for ARC files. However, the SYSOP can install a Verbose List function for
files with extension "xyz". All the SYSOP must do is put a .BAT file with
the name "Vxyz.BAT" on the same disk and path specified for COMMAND.COM via
CONFIG parameter 105. If such a file is present, RBBS-PC will shell to the
file whenever a caller asks for a V>erbose listing of any file with the
extension "xyz". SHELLing requires EXTRA memory beyond what RBBS-PC uses.
If your system has little or no free memory, you may be limited to using
the internal V>erbose list feature of RBBS-PC.
RBBS-PC includes the following files for external verbose list:
ARCVIEW.COM - Compiled C program for verbose list of DWC, PAK, ZOO,
and ARC files. Used in VDWC.BAT, VZOO.BAT.
VDWC.BAT - Processor for DWC files
VZOO.BAT - Processor for ZOO files
Each BAT file contains in it:
ARCVIEW [1] > [2]
RBBS-PC will SHELL to the above program (not to the BAT file) after first
substituting the name of the file to be listed for "[1]" and the name of
the file containing the results of the listing for "[2]". The ">" simply
redirects the listing that would normally go to the screen to "[2]".
RBBS-PC always expects the results of the verbose list to be written to a
file named "NODExWRK" when x is the node id (1,2,3,...).
How to Implement Your Own Verbose List
--------------------------------------
Your verbose list program must have a way to receive from RBBS
o the name of the file to list
o the name of the file to write the listing to.
RBBS will interface with your program in two different ways, depending on
how many lines your BAT file contains.
If the BAT file contains exactly 1 line, RBBS will shell to the line in the
BAT file and not the BAT file. RBBS will dynamically scan for "[1]" and
"[2]" in the line and substitute the names of the file to be listed and the
file to write the results to, respectively. Everything else will be left
intact.
If the BAT file contains more than one line, RBBS will shell to the BAT
file, passing on the command line first the name of the file to list, and
RBBS-PC CPC17-2A Page 94
second the name of the results file.
For example, the following BAT file could be used:
ECHO OFF
ARCVIEW %1 > %2
ECHO ON
Remember, inside a BAT file you can do any processing you want. For
example, if you want to keep a log called VIEW.LOG of the names of
all files viewed, you could have
ECHO %1 >> VIEW.LOG
ARCVIEW %1 > %2
The ">>" means to redirect the standard output to file VIEW.LOG but appends
rather than replaces.
Using Ziptv
-----------
Ziptv is a program distributed by Samuel H. Smith which supports not only
verbose list, but the ability to list any file inside of a ZIP file, thus
allowing users to view documentation before downloading a file. Many
sysops will want to install ZIPTV to replace the internal RBBS verbose
list. Simply make sure ZIPTV.EXE is either in the current directory or the
path, and put VZIP.BAT where config says that COMMAND.COM is.
RBBS-PC CPC17-2A Page 95
9. UNIQUELY IDENTIFYING YOUR CALLERS
-------------------------------------
All callers need a way to identify themselves and to re-identify themselves
on subsequent calls so that they can, for example, read the mail addressed
to them. RBBS-PC expects each caller to set a password so that other
callers cannot easily pretend to be that caller. Callers are most easily
known on bulletin boards the same way they are known in real life - which
is usually by first and last name. This is why the default configuration
in RBBS-PC uses first and last name to IDENTIFY users. The first/last name
is the callers identify or ID.
RBBS-PC also allows the SYSOP to identify callers uniquely by something
other than their first and last names. Perhaps the SYSOP wants a one word
alias like AVENGER to be allowed or perhaps callers must use a preassigned
access code (access code, employee number, account number, etc.). RBBS-PC
allows ANY FIELD inside the users file to be used for identification.
Since there are empty, unused areas in the user file, a SYSOP can even
CREATE A NEW FIELD to be used for caller identification.
When anything other than name is used to identify users, RBBS-PC still
wants callers to specify their names. It just does not use that
information to identify them.
A fairly common problem on bulletin board systems with large user lists is
that two callers can have the same first and last name. A caller discovers
this when they are unexpectedly asked for a password on the first call to a
new system, indicating that another caller has already used that name.
Further, since RBBS-PC is used world-wide many non-English speaking
countries (i.e. in Europe, South America, the Far East) have callers with
names that have embedded blanks, etc. RBBS-PC alleviates this problem by
allowing interior blanks in first and last names. Thus JIM JONES can
register as JIM K JONES or JIM JONES SR or JIM JONES III.
By allowing ANY field inside the user record to be used to uniquely
identify individual callers, RBBS-PC alleviates the basic problem of having
two callers with the same name.
This additional INDIVIDUATION field is used to distinguish callers with the
same ID. The way this works is that callers will have to specify both the
identifying and individuation field and both are used to match record in
the users file. This individuation field can likewise be a new field
created by the SYSOP. For example, the SYSOP can specify that callers be
uniquely identified by both their name and their CITY/STATE. Alternatively
the SYSOP can specify that callers are to be uniquely identified by their
telephone number, which would be a new field for RBBS-PC to store.
RBBS-PC CPC17-2A Page 96
9.1 Setting Up Identifying and Individuation Fields
----------------------------------------------------
The identifying and individuation fields in RBBS-PC are controlled by
parameter 41, parameter 42, parameter 43, parameter 44, parameter 45, and
parameter 46 in CONFIG. The default is to use the caller's first and last
name to uniquely identify a user.
The fields available to uniquely identify a caller (other than the caller's
first and last name) are designated in CONFIG by the starting position in
the users file and length. It is essential therefore to understand WHERE
FIELDS ARE STORED IN THE USER FILE. Consult Appendix A for the detailed
layout of the user file.
RBBS-PC's flexibility requires caution to be exercised when selecting the
locations of fields used to identify and individuate, because options can
be selected that make no sense. For example, it is possible to specify the
user preference field, which means that every time a user changed
preferences, such as default protocol, the user would become a different
user.
There are only two fields in the user file that make sense for identifying
users:
1. first/last name (column positions 1-31), or
2. a field designated by you as the SYSOP for your RBBS-PC. For a
SYSOP-designated field, only 4 choices make sense:
a.) none,
b.) name (columns 1-31),
c.) city/state (columns 63-86), or
d.) positions 87-97 in the user record currently "unused."
Positions 87-97 of the users file currently unused provides a potential 11
columns to use for special, SYSOP designated fields. However, there is no
guarantee that these positions will not be used in later releases of RBBS-
PC. Additional fields will be used from the far right. Any SYSOP
intending to utilize this area of the users record is safest if the field
selected begins in column 87 and is as short as possible. The shorter it
is, the more likely there will be room in later releases. For example, 11
columns might be used for telephone number (format 123-1234567). Or 5
columns might be used for account number.
When a special field is created, the SYSOP must also supply the prompt to
be used with the field, since RBBS-PC has no way of knowing how to describe
the field to a caller. The prompt is what is displayed to the caller when
asking for the value of the field.
RBBS-PC uses the callers first and last name for the "to" and "from" fields
for messages even when the users name is not the field used to uniquely
identify callers.
RBBS-PC CPC17-2A Page 97
9.2 Preloading Identities For Instant Access
---------------------------------------------
SYSOPs that operate bulletin boards that are open to new callers have no
problems giving a new caller instant access -- new callers register, set
their identity and password, and are immediately on.
SYSOPs that operate bulletin boards that are only available by
subscription or who delay access operate differently -- a user must
already know and be able to state identity, individuation, and password in
order to get on. To add a new user, the values of these fields must be
communicated back to the caller in order for them to have access. To
overcome this cumbersome approach, some SYSOPs allow new callers on their
system (albeit at a security level so low that the caller can do little, if
anything) and simply raise the security level of the caller once the caller
has met whatever criteria the SYSOP has set for access to the system.
Typically new callers must call back and continue to check to see if their
security level has been raised. Systems that do not let new callers on
require the SYSOP to enter the appropriate information for each new user,
contact the new caller by mail or phone, and let them know how to get on.
Both approaches introduce delays to new callers for getting on and
additional time, expense and overhead for the SYSOP.
RBBS-PC provides a systematic solution to the problem of delayed access for
new user! A SYSOP can add a user WITH NO VALUE FOR THE INDIVIDUATION FIELD
OR PASSWORD. These fields can be left blank. When a caller logs on with a
proper ID and RBBS-PC finds an individuation value or password that is
blank, it lets the caller set the value of those fields without requiring a
match. Subsequent calls, but not the first, must match the value set for
individuation and password.
Even though a SYSOP can add a user and leave the password and individuation
blank, this still requires that the SYSOP add the user only after an ID is
agreed to by both parties. What if this access is still not fast enough?
The solution provided by RBBS-PC is for the SYSOP to "pre-load" IDs and
give out a pre-loaded ID to the caller for instant access, so that the
client does not have to wait even for the SYSOP to add the ID. Since there
is no way to set in advance how a user wants to be identified, the SYSOP
can set up essentially random account IDs which are difficult to guess and
give these out.
Callers willing to charge subscription fees on their credit cards over the
telephone can be given a valid pre-loaded ID for instant access. The
ability of RBBS-PC to use any field for an ID, and let the first call set
individuation and password, means that RBBS-PC can support boards where
instant access is a critical part of their service.
RBBS-PC CPC17-2A Page 98
10. RBBS-PC's AUTOMATIC SUBSCRIPTION/ TIME MANAGEMENT
-----------------------------------------------------
RBBS-PC has support built into it for managing access based on the date of
the call and the time of day. As with the other RBBS-PC features, this
support is optional. The primary uses of this facility are
1. to make it very easy to control access based on subscription dates.
2. to give callers a temporary, date limited boost in privileges.
3. to vary the amount of time that a call can have for a session
based on the time of day.
The subscription management system dramatically reduces the work necessary
for subscription maintenance. After a user is registered, RBBS-PC will
AUTOMATICALLY
1. warn users before their subscription expires
2. reduce the security of callers whose subscription has expired.
In effect, a subscription RBBS-PC can be left on "automatic" pilot and it
will operate correctly, without additional effort on the SYSOP's part.
The subscription and time management system can also be used to grant
callers a temporary boost in privileges. For example, giving new callers a
"free" trial period.
Just as cable TV channels that sometimes have a free week of viewing to
attract new subscribers by letting them know what they are missing, a SYSOP
of a subscription RBBS-PC can set up limited free offers. By setting up a
default subscription period of say, 5 days, all new callers can be let onto
to see whether they want to subscribe. After 5 days, security drops back
down to a more limited level. This "free" period can be made a standing
offer, or turned off after a two week period. Or, a user who requests a
trial period can be individually added with a short subscription period.
Limited trial subscriptions also are an attractive alternative for those
SYSOPs that do not give full privileges until after a caller is verified or
checked out. These callers are either asked to fill out a registration
form or leave a comment, then sometime later the SYSOP decides whether to
increase the security level. By letting new users have a short
registration period with higher privileges, say 3 days, a SYSOP may choose
to give new callers immediate access and minimize the pressure to check the
new caller out as soon as possible. The SYSOP need do nothing if a caller
cannot be verified. Those that check out get their security raised. This
way the many honest new users are not penalized but the prank or dishonest
callers can get on only briefly.
RBBS-PC CPC17-2A Page 99
10.1 Setting It Up
------------------
The subscription management system is turned on by specifying in CONFIG to
limit callers by subscription date. After access is so limited, RBBS-PC
automatically records the date of the first call. For old users, this will
be the first call made since the subscription date began to limit access.
This recorded date is the base registration date. The SYSOP then needs to
specify in CONFIG:
1. A default subscription period (the number of days a new user gets).
2. A warning period (which determines when callers will get an
advance warning that their subscription is about to expire. The
warning period is the number of days left needed to trigger a warning.)
3. The security level expired subscribers get.
In the PASSWRDS file, the SYSOP designates different subscription periods
for each security level (other than the default security level). This
needs to be specified only if a subscription period is desired that will
override the default.
RBBS-PC determines when the subscription will expire by adding the
subscription period to the base registration date. Persons calling after
this expiration date are bumped down to the expired security level set by
the SYSOP in CONFIG.
The time management of RBBS-PC is automatically activated when the presence
of the PASSWRDS file is detected. See section 16.3 for a complete
description of the PASSWRDS file.
RBBS-PC CPC17-2A Page 100
11. USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC
---------------------------------------------------
The RBBS-PC.DEF file is created by the CONFIG program and contains the
program's default operating parameters and values. When you run the
CONFIG program to create RBBS-PC.DEF or to update it, you can change
many of these parameters to meet your needs. Certain parameters which
control critical operations of the programs are embedded in the RBBS-PC
program and should not normally be changed by the system operator. When
setting RBBS-PC is set up for the first time, SYSOPs are urged to take the
default values generated by CONFIG except for those parameters that are
unique to their configuration (i.e. the communication port, etc.).
CONFIG.BAS, unlike Gaul, is divided into many parts or screens. They are:
Screen Description
1 Global RBBS-PC Parameters (Part 1 of 3)
2 Global RBBS-PC Parameters (Part 2 of 3)
3 Global RBBS-PC Parameters (Part 3 of 3)
4 RBBS-PC System Files (part 1)
5 RBBS-PC System Files (part 2)
6 Parameters for RBBS-PC "doors"
7 Parameters for RBBS-PC Security (part 1)
8 Parameters for RBBS-PC Security (part 2)
9 Parameters for Multiple RBBS-PC's and "conferences"
10 RBBS-PC Utilities
11 Parameters for RBBS-PC's File Management System
12 RBBS-PC Communications Parameters (part 1)
13 RBBS-PC Communications Parameters (part 2)
14 RBBS-PC Net Mail
15 New users parameters
16 Use of the Library Sub-System
17 RBBS-PC Color parameters
18 Reserved for future use
The user may scroll forward or backward through the 17 screens of
parameters in CONFIG using the PgUp and PgDn keys on the keyboard.
Additionally users may go directly to a specific screen by pressing a
function key (F1 through F10) or SHIFT and a function key (shift/F1 through
Shift F7) corresponding to the page to be selected. To terminate CONFIG,
users need only press the "End" key on the keyboard.
The compiled version of CONFIG can be invoked with the command:
CONFIG <config file>
The <config file> is an optional name of the configuration file to be
created or edited. This assumes that CONFIG.EXE, is on the default disk
drive. The CONFIG utility will write the RBBS-PC definition file,
RBBSxPC.DEF to the default drive.
RBBS-PC CPC17-2A Page 101
11.1 Global RBBS-PC Parameters (Part 1 of 3)
--------------------------------------------
Parameter 1 and parameter 2 request the RBBS-PC system operator's (SYSOP)
name. This is used when someone wants to leave a message for the SYSOP or
when the SYSOP "chats" with someone on-line. The SYSOP name is used to
insure that users are not attempting to access RBBS-PC using the SYSOP name
hoping to get a higher access level. Attempting to logon using the SYSOP
name will result in "LOGON DENIED" and a posting of the attempt in the
CALLERS file. The SYSOP's name can be either a real name such as "Tom
Mack" or an impersonal identifier such as "Physics Department."
The SYSOP's default sign-on mode is set by parameter 3 as either EXPERT
or NOVICE. Unless you are very familiar with the RBBS-PC's command
structure, the SYSOP's sign-on mode should be NOVICE.
The SYSOP can be paged by callers. Parameter 4 allows the SYSOP to set the
"office hours" when a user can page the SYSOP. The IBM PC's bell is
rather insistent, and these hours should be set to match when you will be
within ear-shot of the RBBS-PC. The times are set using a 24-hour
military clock (i.e. 10:00 P.M. is 2200 hours). The SYSOP can override
these hours by activating the page bell via function key 4 on the keyboard
of the PC running RBBS-PC.
Because the bell on an attached printer is usually louder than the one
built into the PC, the SYSOP can elect to have the printer's bell via
parameter 5 whenever the SYSOP is "paged".
Parameter 6 gives the SYSOP the option of electing to have RBBS-PC
automatically take itself off-line if a "disk full" condition occurs. In
previous versions, this was not an option. Now, if the SYSOP has a floppy
disk for uploads that gets full and everything else is on a hard disk, the
SYSOP can keep RBBS-PC from taking itself off-line should the floppy disk
get full.
Parameter 7 is the SYSOP's preference for prompt sounds when input is
required. When this is on, both the remote user and the local SYSOP will
hear the prompt bell when input is required from the remote user.
Parameter 8 of the CONFIG program asks for the maximum amount of time
each user is to be allowed on the system per session. Set the number of
minutes to whatever you are comfortable with, but 72 minutes is a good
setting for starting up. Subsequently you may have to lower this number
once your number of callers increases, in order to keep callers' waiting
times reasonable. This can also be made the maximum time on the system per
day. As described elsewhere, each security level can have its own maximum
time on the system per session specified and it can vary according to
the time of day that the user logs on.
A SYSOP may limit the maximum amount of time any user with the default
security level can spend on your system each day via parameter 9 of
CONFIG. This is helpful if you have a relatively busy RBBS-PC and
want to have as diversified group of callers as possible. Every
security level can have a different maximum time on the system per day and
it may vary based on the time of day that the user logs on. These are
specified in the PASSWRDS file.
RBBS-PC keeps track of the total amount of elapsed time a user is on RBBS-
PC each day. Each time a caller logs on, the maximum amount of time that
they are allowed on the system is checked against this daily cumulative
total. The time remaining in each caller's session is the difference.
RBBS-PC CPC17-2A Page 102
When a caller exceeds this maximum and tries to log on again, they are
told that they have exceeded the allocated time for that day and to try
again tomorrow.
Parameter 10 allows a SYSOP to "reward" users who upload files by adding
some multiple of the elapsed time it took for the file upload to the
current session time. This should be used judiciously as some users may
abuse this by repeatedly uploading COMMAND.COM or some other meaningless
file. This extends both the users current session and other sessions
during the same day, but NOT the time on future days. However when
specifying this parameter, the SYSOP will be asked if upload time credits
are to accumulate indefinitely until they are used. If the SYSOP replies
"NO", the upload time credits endure only for the day in which the uploads
are made.
Parameter 11 sets the number of months inactivity that must elapse before
a user is deleted from the USERS file when the SYSOP "rebuilds" the user
file.
Parameter 12 allows the SYSOP to specify the name of the RBBS-PC that is to
be displayed when a user first connects with the system and prior to
completing the logon process.
Parameter 13, parameter 14, and parameter 15 allow the SYSOP to specify the
colors desired for the foreground, background, and border. When
specifying these options the BASIC manual's section describing the COLOR
command in text mode should be consulted. This is useful when running
multiple RBBS-PC's and you want a handy way of determine which RBBS-PC it
is that you are viewing on the screen. This option is NOT available if
the SYSOP has specified a "ring-back" system.
Parameter 16 control whether RBBS-PC will use ANSI codes for special
effects like blinking on the local PC's screen.
Parameter 17 designates the decimal value ( 0 to 255) of the character to
be used for personalizing the text files displayed to the caller. If 0 is
selected, no text files will be personalized. See section 8.9 for a more
detailed discussion of how to personalize RBBS-PC text files.
Parameter 18 allows the SYSOP to specify the file name that contains the
information to control the "automatic" RBBS-PC paging of the SYSOP. See
section 8.11 for a detailed description of the file format and a
description of RBBS-PC "auto-page" feature.
Parameter 19 lets the SYSOP determine the level of detail to use when
notifying callers of electronic message. See section 19 to get a better
understanding of the full flexibility of mail waiting notification that has
been built into RBBS-PC.
RBBS-PC CPC17-2A Page 103
11.2 Global RBBS-PC Parameters (Part 2 of 3)
--------------------------------------------
Parameter 21 allows the SYSOP to remind users not only of the messages
that might be for them but also messages that they may have left. This
should be enough of a nuisance to insure that users do delete some of the
messages they have left and help to keep the MESSAGES file to a minimum.
Parameter 22 allows the SYSOP to elect to remind users of how many files
they have downloaded and uploaded.
Parameter 23 allows a SYSOP to remind users every time they log on of the
preferences they have selected for such things as file transfer protocol,
graphics, nulls, etc.
Parameter 24 allows users to download files immediately upon logging on to
RBBS-PC. Parameter 24 is only meaningful if the RBBS-PC File Management
System (FMS) has been enabled via parameter 214. RBBS-PC will scan this
file for the latest uploads. When a caller logs on, RBBS-PC will determine
how many files are new since the caller last logged on, up to a maximum of
23. By setting parameter 218, the caller is offered the chance to
immediately review these new files for downloading, if the caller has
sufficient security to download. This happens before the bulletins or
messages are reviewed. RBBS-PC's that emphasize software exchange may want
to enable this option, others may not want to give the caller a chance to
download the new files until after bulletins and messages have been
reviewed.
Parameter 25 allows the SYSOP to establish a default page length for users
when they log on. A 23 line page length is the default, but the SYSOP
can set it to any number between 0 and 255. If set to 0, the user
will receive continuously scrolling output.
Parameter 26 allows the SYSOP to specify (within the range of 1 to 99) the
maximum number of lines allowed in each message.
Parameter 27 allows the SYSOP to make the system "welcome" file
interruptable. The default is that YES it is interruptable. However, if
the SYSOP feels too many people are bypassing it and it contains essential
information, the SYSOP can set this parameter to NO (i.e. the user can not
suspend or cancel the listing of this file at their terminal with a CTRL S
or CTRL K).
Parameter 28 is intended to allow the SYSOP to indicate if the system
bulletins are to be optional for users when they log on. If bulletins are
optional, callers can elect to automatically bypass old bulletins and be
notified only when there are new bulletins. RBBS-PC will check the file
date of the bulletins and inform the caller which are new, with the option
to read all of the new bulletins. If none are new when bulletins are
optional, the bulletins will be automatically bypassed.
Parameter 29 is designed to allow RBBS-PC to run on some "IBM-compatible"
PC's that make use of unused interrupts or on the IBM PCjr. RBBS-PC
checks to see if the unused interrupt X'7F' is non-zero. If it is, RBBS-PC
thinks that the software product, MultiLink (from The Software Link, Inc.)
is present and issues the appropriate MultiLink calls. Obviously if this
is not the case, strange and unpredictable things happen which result in
RBBS-PC not working. The COMPAQ+ is an example of this syndrome.
If running RBBS-PC on an IBM PCjr using an external modem but without an
internal modem, the communications port must be opened as COM1 even though
RBBS-PC CPC17-2A Page 104
RBBS-PC must use the COM2 RS-232 registers for controlling the
communications port.
Parameter 30, parameter 31, parameter 32, parameter 33, and parameter 34
let the SYSOP change what symbols are used for each RBBS-PC function by
substituting a new letter. Additionally, a space substituted for a
command will disable that command, in effect removing it from the system.
SYSOPs with no DOORS may wish to disable D rather than to confuse users by
displaying options not available. All commands displayed to callers in the
command prompt will be in sorted order.
Parameter 35 allows the section name to precede the command prompt that is
displayed when a caller is asked to enter a command. The command prompt
begins with <section>, where <section> is MAIN, FILE, or UTIL, if this
option is selected. Otherwise, the prompt will begin with YOUR. Normally
the section in the prompt helps the caller remember where he is, but see
section 8 for reasons to suppress the section.
Parameter 36 allows the SYSOP to not display the commands to the caller
when waiting for the user to enter a command. The default in RBBS-PC is to
remind the caller what commands are available by giving a sorted list of
the letters used for each command at the end of the command prompt. RBBS-
PC shows only the commands available in the section that the caller is in.
If the SYSOP chooses not to display the section a user is in, there are
more commands available than will be shown in the prompt.
RBBS-PC supports a "wrap-around" search for valid commands. This means
that when a command is not found in the current section, other sections are
then searched. The order of search is MAIN->FILE->UTIL->LIBR. For
example, if L is picked when in the main section, where there is no
command, the L)ist command in the file section will be executed. Parameter
37 lets the SYSOP turn this wrap-around search and not execute commands in
other sections. Wrap-around is required if the SYSOP want's to have a
single command line (i.e. not have the "Utility" and "File" subsystems).
Parameter 38 allows the SYSOP to elect to use machine language subroutines
(rather than the BASIC routines) for a few of the more commonly used
subroutines. These may only be functional within a DOS that is supplied by
IBM (rather than Microsoft). Therefore this is optional. If you encounter
problems, simply elect to utilize the BASIC routines which are much more
likely to be compatible in configurations that have hardware and software
operating environments significantly different from the "baseline"
configuration in which RBBS-PC is tested. In most cases the assembler
routines are much faster than their BASIC counterparts, especially in file
searches.
Parameter 39 allows the SYSOP to elect to use the BASIC language's PRINT
statement to write to the screen of the PC that RBBS-PC is being run on.
This is sometimes necessary in "hostile" environments (i.e. multitasking,
special screen drivers, etc.) where the use of RBBS-PC's default call to
the RBBS-PC screen driver ANSI is not viable.
Parameter 40 is the maximum number of lines that can be used to describe a
file that was uploaded. It is the number of lines (beyond 1) that a caller
can enter when describing a file that was uploaded. It applies to both
single FMS directories and non-FMS directories.
RBBS-PC CPC17-2A Page 105
11.3 Global RBBS-PC Parameters (Part 3 of 3)
--------------------------------------------
Parameter 41 and parameter 42 determine how callers are going to be
uniquely identified when they log on. The default in RBBS-PC is to
concatenate first and last name to form name. Parameter 41 lets SYSOPs
choose another field as user ID. A field is specified by giving its
starting position and length in the user file, and a prompt must be
supplied which will be used when asking for user ID. BE VERY CAREFUL
CHANGING THIS PARAMETER. Parameter 45 and parameter 46 allow the SYSOP to
specify a name to be used when prompting the user for the field (i.e.
ACCOUNT #). See section 9 for additional details. RBBS-PC assumes that
name is being used whenever the ID begins in column 1.
Parameter 42 lets a field be specified that will be used to distinguish
callers with the same ID. Like with ID, the beginning column, length, and
prompt must be specified. RBBS-PC defaults to no individuation, which is
specified by setting the beginning column to 0. Activating this option
forces users to give additional information when they log on, since both ID
and individuation value have to be given. See section 9 for details on how
to use this option.
Parameter 43 and parameter 44 inform RBBS-PC the field and the length of
the field in the USERS record to use when determining if a "personal
download" exists for this person. Parameter 43 indicates where the field
begins in the USERS record -- the default is position 1 (the user's name).
Parameter 44 indicates how long the field to match against is -- the
default is 31 (the maximum length of a user's name). The entries in the
personal download directory must have exactly this many bytes at the end --
plus one (for the flag used to indicate if the file has been download).
Parameter 45 and parameter 46 allow the SYSOP to specify the description of
what is asked for that is placed in the first 31 bytes of each user's
record. When identifying to whom a message is to/for it is these 31 bytes
that are matched against. However, these prompts can be changed from the
default "FIRST name" for parameter 45 to "REAL FIRST name" or even "DEALER
number". Similarly the default for parameter 46 could be changed from
"LAST name" to "ZIP code".
Parameter 47 allows the user to enforce upload to download ratios. See
section 16 for a discussion of the flexibility each RBBS-PC SYSOP has in
specifying these ratios. Sections 16.3 and 16.4 describe in more detail
the format necessary to use in the password file in order to utilize which
users/security levels are to have upload and download ratios applied.
Parameter 48, parameter 49, parameter 50, and parameter 51 address access
control via the automatic RBBS-PC subscription management facilities. For a
detailed discussion of RBBS-PC's automatic subscription management
facilities, see section 10. Parameter 48 means that access will be
controlled by subscription dates, and persons with expired subscriptions
will get reduced privileges. Parameter 49 is the security level callers
get after their subscription expires. Typically this security
significantly reduces what a caller is allowed to do. Parameter 50
specifies when callers are to be warned in advance that their subscription
is about to expire. This warning is based on the number of days before a
subscription expires. Parameter 51 specifies the number of days a new user
gets in the subscription period.
Parameter 52 determines if RBBS-PC is to avoid writing to the printer. On
some networks any attempt to write to a printer can generate a spooler
error that hangs the node. Setting this parameter to "YES" guarantees that
RBBS-PC CPC17-2A Page 106
RBBS-PC doesn't write to the printer.
Parameter 53 causes RBBS-PC to play musical themes for auditory feedback on
what is happening on a board. This can be important for SYSOPs that are
sight impaired. These musical themes are "played" on the speaker of the PC
that is running RBBS-PC. The themes are not transmitted to the caller.
Parameter 54 is the buffer used internally by RBBS-PC when displaying text
files such as menus, directories of files, etc. A SYSOP can set parameter
218 to either minimize memory usage or optimize speed. It is the size of
the internal buffer that RBBS-PC uses to read in most text files, including
menus and can range from 32 bytes to 4096 bytes. The bigger the buffer,
the fewer disk accesses necessary to display the file and the faster the
display will be. The default of 128 is the minimum recommended.
Increasing this to 512 will increase the speed of text displays. However
in some environments where it is important to respond quickly to XON/XOFF
control, this should be set to the minimum of 32.
Parameter 55 allows RBBS-PC to dynamically set the "stack space" used by
the code generated by the BASIC compiler. In QuickBASIC 3.0, the compiler
used to generate RBBS-PC's .EXE file, and IBM's BASIC Compiler Version 2.0
this is the total stack space. In later releases of QuickBASIC, it is the
ADDITIONAL stack space beyond which BASIC normally allocates. The
recommended value is 1024, if RBBS-PC is running in a multi-tasking
environment under DOS. However, in order to decrease memory demands this
can be made smaller.
Parameter 56 is not implemented in RBBS-PC.
Parameter 57, like parameter 45 and parameter 46, is used when a new user
logs on to the system for the first time. Instead of asking a user for
their City and State, a SYSOP can request such things as their area code
and telephone number.
Parameter 58 allows the SYSOP to configure RBBS-PC such that the file
directories are shown in sorted order whenever a caller simply lists the
directory of directory.
Parameter 59 allows the SYSOP to configure RBBS-PC such that the "internal"
RBBS-PC protocols use as large (or as small) a buffer size when writing to
disks (i.e. for uploads). The allowable range is from 128 characters to
8,192 characters.
Parameter 60 indicates that Computalker (B.G. MICRO, P.O. Box 280298,
Dallas, Texas 75228) or HEARSAY 1000 (HEARSAY Inc., 1825 74th Street,
Brooklyn, N.Y. 11204) speech boards are to be supported. This is in
support of the sight impaired SYSOPS. These two particular boards were
selected since they were available from John Lasley. (John is a SYSOP in
Minneapolis, MN).
To support as many speech boards as possible in the future, RBBS-PC uses a
64 entry file (RBBSTALK.DEF) to contain SYSOP-defineable fields. The file
is accessed randomly with fixed-length 32 byte records. The last two bytes
must contain CR/LF leaving 30 bytes available for the verbage. The 64
records are predefined and used by RBBS-PC as follows:
1 = LOGON USER MESSAGE
2 = MAIN MENU PROMPT
3 = FILES MENU PROMPT
4 = UTILITY MENU PROMPT
RBBS-PC CPC17-2A Page 107
5 = DOOR MENU PROMPT
6 = LIBRARY MENU PROMPT
7 = LOGOFF MESSAGE
8 = DOWNLOAD PROMPT
9 = UPLOAD PROMPT
10 = TIME REMAINING PROMPT
11 = WELCOME BACK PROMPT
12 = CONFERENCE MENU PROMPT
13-64 available for future enhancements
Smarttext IS supported in the RBBSTALK.DEF records.
The CompuTalker requires the use of one of the COM ports. With CPC17-2A it
is supported on COM2. CPC17-2A does not check to see if COM2 was also
selected for CONFIG parameter 221.
RBBS-PC CPC17-2A Page 108
11.4 Parameters for RBBS-PC System Files (part 1)
-------------------------------------------------
Parameter 61 specifies the name of text file that is shown to a user if
bulletins are not optional (see parameter 28) or if the user replies "L"
when notified of how many bulletins exist. This file should contain a list
of the bulletins (i.e. 1-99) and a brief one-line description of the
contents of each (e.g. "New Release of RBBS-PC").
Parameter 62 allows a SYSOP to have from 0 to 99 "bulletins." If there are
0 bulletins a user is notified that there are no bulletins. Bulletins
should be brief, informative, and timely. I personally think that there
should be very few bulletins and that they should be changed often if users
are to be enticed to look at them. If you make bulletins optional
(parameter 28) RBBS-PC will automatically bring new ones to the attention
of each caller when they log on.
Parameter 63 provides the SYSOP with the flexibility to make the prefix of
the bulletins anything he wants (i.e. BULLET). To this is added the number
(e.g. BULLET7 for bulletin number 7) and the disk drive designated in
parameter 61 is searched for the bulletin number requested when some asks
to see a bulletin. If the file is not found, the user is so informed. If a
"graphics" equivalent is found and the user has signed on N/8/1 and
requested graphics, the graphics version of the bulletin is displayed -
BULLET7G (i.e. contains characters with values of 0 through 255) or
BULLET7C (i.e. contains characters with values of 0 through 128 which,
hopefully, are ANSI screen commands).
Parameter 64 indicates the disk drive and path on which RBBS-PC is to
search for to find RBBS-PC's on-line "help" files whenever a user asks for
help within a specific subsystem. This is where the help files should be
stored.
There are some specific help files used by RBBS-PC whose name is simply a
help prefix plus a number. The SYSOP may elect to call the prefix
something other than the default of "HELP0". Parameter 65 allows the SYSOP
to pick up to a seven-character prefix to which the numbers will be
appended. This file name is what RBBS-PC will look for on the drive
specified in parameter 64 when a user asks for help on-line. As with
"bulletins", if a "graphics" equivalent is found and the user has signed on
N/8/1 and requested graphics, the graphics version of the help file is
displayed (i.e. HELP07G).
RBBS-PC identifies help for a particular command by the letter of the
section and the letter of the command, plus an extension for the help
files. The extension "HLP" is the default but parameter 66 lets the SYSOP
set this to whatever desired.
Parameter 67 is the name of the file that is displayed to a caller when the
caller is requested to categorize a file that has been uploaded. RBBS-PC'
File Management System can be configured to minimize the activities of the
SYSOP by allowing users to categorize the files that are uploaded. This
file should list the names of the categories that an uploader can select.
It should be stored on the same drive and path as the other help files. The
category selected will be validated to make sure that it is in the list in
DIR.CAT or that a valid category file with that name exists. The
appropriate category code will be written out to the shared FMS directory
if the FMS system is active. If the FMS system is not being used or a
separate .DIR file with the category name exists (e.g. GAMES.DIR), the
description of the entry for the upload will be appended to the .DIR file.
RBBS-PC CPC17-2A Page 109
Parameter 68 allows the SYSOP to select any name for the text file that new
users see when they first log on and before they "register" themselves in
RBBS-PC's USERS file. A user sees it once and only once during his first
session. It can contain anything you want it to, but a brief explanation
of your Board's purpose, "rules", etc. might be appropriate.
Parameter 69 allows the SYSOP to select any name for the text file that
each user sees EVERY time AFTER they log on. Keep it brief! RBBS-PC will
look for a "graphics" equivalent if the user qualifies for graphic displays
(i.e. it will display the file HELLOG or HELLOC in lieu of HELLO). The
default name for this file is WELCOME.
Parameter 70, parameter 71, parameter 72, parameter 73, parameter 74, and
parameter 75 focus on the text files that RBBS-PC displays to novices as
"menus." Menu files shown to novices tend to be frequently accessed.
Systems that do not have disk caching should consider putting menus in a
RAM disk in order to cut down on the wear and tear of your disk drives.
Parameter 70 allows any valid name to be given to the text file containing
the commands allowed those with SYSOP privileges.
Parameter 71 allows the SYSOP to specify the name of the text file
containing the menu of commands available to those in the main "messages"
subsystem.
Parameter 72 allows the name of the text file containing the menu of
commands available to those in the "files" subsystem to be any valid name.
Parameter 73 allows the name of the text file containing the menu of
commands available to those in the "utilities" subsystem to be any valid
name.
Parameter 74 is the name of the text file listing the names of the
conferences that are available. Conference names must be seven-characters
or less, in all caps, and cannot have any character to the left or right of
the name except possibly a space. The SYSOP must already have pre-
formatted the messages and users files associated with the conferences (see
section 18).
Parameter 75 allows the SYSOP to name the text file containing the list of
the questionnaires, surveys, or forms which callers can fill out and answer
on-line. The scripting support built into RBBS-PC allows the SYSOP to
construct a series of questions to be presented to the caller and save the
answers. Questionnaire names must be eight characters or less, in all
caps, and cannot have any character to the left or right of the name except
possibly a space. Of course, the actual file name for the script has an
extension of ".DEF". Thus, a questionnaire called SURVEY would appear in
the text file identified in Parameter 75 as SURVEY, preceded and followed
by at least one blank character, and exist as a file named SURVEY.DEF.
Parameter 76 allows the SYSOP to specify the drive and path where the
optional questionnaires will be located.
If the file specified in parameter 77 exists, RBBS-PC will assume that the
SYSOP is using RBBS-PC's "Programmable User Interface" (PUI) -- see section
8 for a fuller description of RBBS-PC's PUI.
Parameter 78 allows the SYSOP to elect to have RBBS-PC have full page
control. By this it is meant that all displays will be interrupted after
the number of lines set by the user for his "page length" have been written
RBBS-PC CPC17-2A Page 110
to the user's screen. This, on occasion, may mean that menus will pause in
the middle with a prompt waiting for the user to hit enter. The advantage
of allowing this to happens means that no information on the user's screen
will "scroll off" the top of the screen. The disadvantage is that menus
may not be viewed in their entirety. Replying "NO" to this parameter means
that menus will be fully displayed on a single screen, but some information
that preceded the menus may scroll off the top of the screen.
Parameter 79 and parameter 80 allow the drive, path name, and extension to
be used for RBBS-PC "macros". See section 8.8 for a fuller description of
RBBS-PC extensive "macro" capabilities.
RBBS-PC CPC17-2A Page 111
11.5 Parameters for RBBS-PC System Files (part 2)
-------------------------------------------------
Parameter 81 is the name of the text file (TRASHCAN) listing names that the
SYSOP considers inappropriate. This file is used when a new user signs on.
The new users first and last name are each individually checked against
the names in this file, as well as the entire name.
The format of this file is as follows:
<name>,
An example of such a file would be:
BITE,
BYTE,
PAPA DOC,
DOCTOR,
DEATH,
GLADIATOR,
KILLER,
MAN,
THE
The comma is optional after each name. However, it does help in
delineating exactly what character strings are being searched for and
compared against (some text editors may add extraneous and non-visible
characters to a line). All names should be UPPER CASE! If you create the
file using IBM's standard DOS text editor, EDLIN, each line may end with
either a comma or a carriage return. If you create the file using COPY
CON, each line should end with a carriage return (i.e. the "enter" key).
The last line (when using COPY CON) should end with a Control Z, F6, and
then carriage return. BASIC will treat either a comma or a carriage return
as a field delimiter. You need a field delimiter following each of the
names. If the above file existed, any new user who logged and used the
following names would be denied access:
Byte Killer
Kilo Man
Doctor Death
PC Doctor
Pappa Doctor
but "Hoppa Papa" would be fine.
Parameter 82 lets the SYSOP force a questionnaire to be answered by all
callers, old and new, exactly once. RBBS-PC records in the users record
when the required questionnaire is answered so that it will not ask the
caller again. Parameter 186 lets the SYSOP reset the flag back to off for
all users. This should be done when the SYSOP wants to install a new
required questionnaire to be used to survey all callers. If no
questionnaire is required, this parameter can be specified as NONE.
Parameter 83 allows the SYSOP to specify the name of the file that will be
displayed as soon as carrier is detected and BEFORE a user can log on. It
is displayed immediately after the name of the RBBS-PC is shown (see
parameter 12). SYSOPs should use "PRELOG" to convey such information as
whether real names are required, 300 baud users will automatically be
denied access, etc.
RBBS-PC provides a sophisticated, script-driven capability that allows a
RBBS-PC CPC17-2A Page 112
SYSOP to ask new users questions or questions of all users when they say
G>oodbye. Parameter 84 allows the SYSOP to specify the file name of the
script of questions to ask new users.
Parameter 85 allows the SYSOP to specify the file name of the script of
questions (if any) to ask users when they say G>oodbye. The SYSOP can set
up the script so as to raise or lower a new users security level based on
the answers. Contained within these scripts is the file name to which the
answers are to be written.
Parameter 86 allows the SYSOP to specify the file name for the file used by
RBBS-PC to hold the messages on the bulletin board. This file can NOT have
an extension because RBBS-PC appends the extension ".BAK" to the file name
when "packing" the messages file.
NOTE: Read section 19 if you want to include the main message file in the
scan for conference mail waiting.
RBBS-PC keeps a profile of each user who logs on in a "user record" (see
Appendix A for a layout of this record). Parameter 87 allows the SYSOP to
specify the file name for this file. This file can NOT have an extension
because RBBS-PC appends the extension ".BAK" to the file name when
"packing" the users file.
Instead of leaving a "message", a user may leave a comment for the SYSOP
that is readable only by the SYSOP. Parameter 88 allows the SYSOP to
specify the fully qualified name for the file used by RBBS-PC to store
users' comments.
Parameter 89 allows the SYSOP to have comments recorded as private messages
to him in the main messages file providing there is any room. This allows
replies to comments to be done much more easily.
RBBS-PC maintains a log of user activity on a "callers" file. It contains
information on the date, time, communications parameters of who logged on;
what they uploaded or downloaded; and any security violations or errors
that were generated. Parameter 90 allows the SYSOP to specify the fully
qualified name for the file that RBBS-PC uses for this log.
If parameter 91 is selected, additional items of information are included
in the CALLERS file:
1) "Connect not completed" 9) "Left comment at time"
2) "Sleep disconnect" 10) "Logged off at time"
3) "Caller changed name/address" 11) "Carrier dropped at time"
4) "Newuser" 12) "Message # xxxx left at"
5) "Bulletin x read" 13) "Read Messages ..."
6) "SYSOP initiated Chat" 14) "Answered questionnaire xxx"
7) "Entered Conference/Subboard x" 15) "Killed msg # xxxx"
8) "Time limit exceeded"
It should be remembered that for each occurrence of the above, the CALLERS
file will increase by 64 bytes. Unless you either have a hard disk or are
willing to frequently maintain your system in order to leave enough free
space on the disk drives for new files, this option should NOT be
activated.
Parameter 92 has not been implemented in RBBS-PC.
Parameter 93 allows the file name to be specified for the file containing
RBBS-PC CPC17-2A Page 113
the information on the conferences that are to be scanned for mail waiting
when a user logs on. The format of this file and the flexibility it
affords the RBBS-PC SYSOP is described more fully in section 19.
Parameter 94 allows the SYSOP to specify the maximum number of "working
variables" that RBBS-PC should support in the questionnaires and macros. A
"working variable" is simply a place in which RBBS-PC can store a response
or a set of characters. These "working variables" can then be used to
create parameters that can be passed to "DOOR"s (see section 15.4) or
written out to data bases (see section 8.8.4).
RBBS-PC CPC17-2A Page 114
11.6 Parameters for RBBS-PC "Doors"
-----------------------------------
Parameter 101 allows the SYSOP to enable RBBS-PC to exit and return to the
system (i.e. DOS). You will also be asked if you will be running "doors"
with MultiLink. If you reply yes, you may choose what type of terminal
MultiLink is to assume the user is using when MultiLink receives control
from RBBS-PC. See the MultiLink manual for the various terminal types. If
you choose terminal type zero, MultiLink will not be given control of the
communications port when RBBS-PC exits to the "door." Use this if your
application is coded to control the communications port. The batch file
out of which RBBS-PC is invoked should then check to see if a "door" is to
be invoked. A "door" is simply a batch file that the SYSOP has created
which RBBS-PC users are allowed to exit to and which will then take control
of the remote users communication port.
Parameter 102 allows the SYSOP to specify the fully qualified file name of
the menu that lists the names of the "doors" available to users. RBBS-PC
checks this file to verify that the name of the door that the user
requested is in the doors menu (see section 15). A door name in the menu
must have 8 or fewer characters, be in all caps, and the only character
that can occur immediately before and after the name is a space.
Parameter 103 allows the SYSOP to specify the fully qualified file name of
the file that RBBS-PC is to use when dynamically building the .BAT file
that invokes the "door" selected by the user. The batch file that invokes
RBBS-PC must contain an "IF" to check if this file exist whenever RBBS-PC
terminates and (if it exists) to execute it (see section 14). This is also
the same file name that is used when the SYSOP exits to DOS.
When a door finishes RBBS-PC is re-invoked. Parameter 104 allows the SYSOP
to specify the fully qualified file name of the .BAT file that should be
used to re-invoke RBBS-PC (see section 14 and section 15). This is also
the same file name that is used when the SYSOP returns from exiting to DOS.
Whenever a remote user exits to a "door" or to DOS (via the remote SYSOP
function 7), RBBS-PC needs to know where to find COMMAND.COM. In a network
environment with several PC's the COMMAND.COM's may be different for each
PC. Parameter 105 allows the SYSOP to specify for the each copy of RBBS-PC
a disk drive and path on which to find the COMMAND.COM appropriate for that
copy of RBBS-PC.
Parameter 106 allows the SYSOP to elect how I/O is redirected to the
communications port when dropping to DOS as a remote SYSOP (command "7").
When configuring RBBS-PC you may select to have the I/O redirected either
via the standard DOS "Change Console Command" (CTTY), or having DOS
redirect standard I/O (">" or "<"). This parameter allows you to specify
if the redirected output is to be handled by a special device named in
CONFIG.SYS. If you don't elect to use a special device driver, RBBS-PC
will redirect the output directly to the communications port by building
the command "CTTY COMx" or ">COMx and <COMx" , where "x" is based on the
communications port the node was configured for. If you specify the name
of a device driver, it should also be in the CONFIG.SYS of the system that
RBBS-PC is running on. As an example, if you specified a device driver of
GATE, RBBS-PC would build the command CTTY GATE.
Parameter 107 specifies the name of a program (i.e. an .EXE or .COM file)
that control is to temporarily to be passed through when the caller is
determined to be a new user. When this .EXE or .COM file finishes and
RBBS-PC is re-invoked, the RBBS-PC logon sequence will continue
uninterrupted from the point at which the caller was determined to be a new
RBBS-PC CPC17-2A Page 115
user. This feature is intended for those who feel the need to perform an
extensive verification of new user's that is not met by RBBS-PC's built in
scripting capability or automatic subscription functions. This feature
allows those SYSOPs who have the need to reference membership lists, verify
political affiliation, interrogate blood type, or "qualify" new users via
whatever criteria seems expedient to their needs/purposes in any way they
wish simply by writing a program external to RBBS-PC.
Parameter 108 allows the external program designated via parameter 107 to
be invoked for not only new callers, but also for callers who have a
security level equal to or less than the security level specified in
parameter 108.
Parameter 109 allows the SYSOP to invoke "DOORS" via a control file. The
control file has 8 parameters that are separated by commas. The format is
1. Name of door - up to 8 characters
2. Minimum security to use door
3. Questionnaire to execute before the door
4. Method to invoke doors - "S" for shelling, else go to .BAT file 5.
Template for invoking door - make sure the first word has a file
extension - RBBS-PC will check for existence of the first word as file.
6. Whether ask for password on return - Y is yes, anything else bypasses
password check
7. File to display after the door
8. Maximum time allowed in doors - time remaining passed to door is
reduced if max time is less.
Note: RBBS-PC normally passes the node id as the 1st parameter to a door.
If a template is used, RBBS-PC will not automatically add this parameter.
If you want it, you should include "[NODE]" in the template. Special note:
A door must still have a .BAT file in order to be invoked, even if the BAT
file is not used in the template! A control file is optional. The
default name is DOORS.DEF.
Example #1:
Given:
1. Name of the "DOOR" is "KEYCHK"
2. Minimum security a caller must have to use the "DOOR" is 4.
3. Questionnaire users must answer prior to entering the "DOOR" is
C:\RBBS\GET3RD.DEF
4. The "DOOR" is to be invoked by EXITing.
5. The template to use is designed to invoke a .BAT file and pass two
different responses acquired from the questionnaire when the .BAT file
is invoked.
6. Returning from the "DOOR" the caller need not reenter their password.
7. The caller is to be shown the file "KEYCHK.FIL" when the "DOOR" ends.
The control file would have the following line in it:
KEYCHK,4,C:\RBBS\GET3RD.DEF,D,"RUNKEY.BAT [1] [2]",N,KEYCHK.FIL,
Example #2:
Given:
1. Name of the "DOOR" is "SKYCHK"
2. Minimum security a caller must have to use the "DOOR" is 10.
3. Questionnaire users must answer prior to entering the "DOOR" is
C:\RBBS\GET3RD.DEF
4. The "DOOR" is to be invoked by SHELLing.
RBBS-PC CPC17-2A Page 116
5. The template to use is designed to invoke a .BAT file and pass two
different responses acquired from the questionnaire when the .BAT file
is invoked.
6. Returning from the "DOOR" the caller must reenter their password.
7. The caller is to be shown the file "KEYCHK.FIL" when the "DOOR" ends.
The control file would have the following line in it:
SKYCHK,10,C:\RBBS\GET3RD.DEF,S,"RUNKEY.BAT [1] [2]",Y,KEYCHK.FIL,
RBBS-PC CPC17-2A Page 117
11.7 Parameters for RBBS-PC's Security (part 1)
-----------------------------------------------
Parameter 121 is the first and last name alias (i.e. pseudonym) that the
SYSOP will use when logging on remotely. It is this alias name that causes
RBBS-PC to recognize the remote caller as the SYSOP and not simply a user
with a security level equal to that of the SYSOP. This should be a first
and last name combination that is not likely to be selected by other
callers. If you want to eliminate anyone from logging on as the SYSOP,
you can simply reply with a "null" (i.e. a carriage return) for the first
and last name for parameter 121.
The ESC key is used to log on in local SYSOP mode. Parameter 122 can be
set so that the pseudonym specified for parameter 121 is required to be
entered from the local keyboard of the personal computer on which RBBS-PC
is running when the escape key (Esc) is pressed. If you enter YES, no
password is required.
Parameter 123 specifies the minimum security level users need in order to
log onto RBBS-PC and parameter 124 specifies the security level assigned
to new users. If the security level assigned new users is less than the
minimum security level to log on, no new users can logon on. This means
that no new users are allowed and access is limited only to pre-registered
users. Since one of RBBS-PC's two objectives is to facilitate the exchange
of information, every RBBS-PC SYSOP is urged to not entirely deny new users
access. The chapters on RBBS-PC's extensive security features and
subscription and time management system detail the ways in which a SYSOP
can control access to his RBBS-PC without having to deny access to new
users -- chapters 16 and 10, respectively.
Parameter 125 specifies the minimum security level a user must have in
order to be considered a SYSOP. Even if a user has a high enough security
level to see the SYSOP menu and execute some or all of the SYSOP commands,
the user will not be treated as a SYSOP (i.e. allowed to see the files
upload/download when viewing the CALLERS file) unless the users security
level is equal to or greater than that specified by this parameter.
Parameter 126 prevents the SYSOP menu from being displayed (even if the
user has a security level of a SYSOP as specified in parameter 125)
unless the user is also at this security level.
Parameter 127 is the minimum security level a user must have to leave an
extended (i.e. multiple line description) of a file that was uploaded. See
parameter 40 for the maximum number of lines that an extended description
will be allowed under the single FMS environment.
Parameter 128 allows a maximum number of security violations (i.e.
attempts to download protected files) before the user is logged off and
locked out.
Parameter 129, parameter 130, parameter 131, parameter 132, and parameter
133 allow the SYSOP to set up the security levels required to issue
the commands in the SYSOP, Main Menu, File Subsystem, Utilities Subsystem
(respectively), and global commands. All the commands in each area can
be given the same security level or, optionally, a specific command can
be given a unique security level.
Parameter 134 allows the SYSOP to specify the maximum number of times
users can change their passwords in a given session. This prevents a
caller from "fishing" for special passwords.
RBBS-PC CPC17-2A Page 118
Parameter 135 is the minimum security level required in order for users to
change temporarily their security or time on the system via privileged
group passwords. If users do not have the minimum security level to
temporarily change their password, ALL password changes that they make will
be permanent -- even if the password they select is in the temporary
password file named in parameter 146 of CONFIG!
Parameter 136 allows the SYSOP to specify a security level that has
the privilege of overwriting files (i.e. files that already exist)
when uploading.
When the SYSOP "purges" the USERS file, all users who have not signed on
within the number of months specified in parameter 11 are deleted from the
file with the exception of those who have been "locked out" and those whose
security level is equal to or greater than that specified in parameter 137.
Parameter 138 allows the SYSOP to specify the security level required to
read new PRIVATE messages. Only those with this security level or higher
can read new private messages -- even if they have been addressed to them.
By setting this value higher than any other user than that of the SYSOP,
the SYSOP can then review all new private messages before allowing them to
be seen by the addressee. After reviewing these messages, the SYSOP can
change the security level so that the message can be seen by the sender and
the addressee.
Parameter 139 allows the SYSOP to specify the security level required to
read new PUBLIC messages. Only those with this security level or higher
can read new public messages. By setting this value higher than any other
user than the SYSOP, the SYSOP can then review all new public messages
before allowing them to be seen. After reviewing these messages, the SYSOP
can change the security level so that the message can be seen.
Parameter 140 specifies the minimum security level that is able to change
the security level of a message.
RBBS-PC CPC17-2A Page 119
11.8 Parameters for RBBS-PC's Security (part 2)
-----------------------------------------------
Parameter 141 is not implemented in RBBS-PC.
Parameter 142 allows the SYSOP to specify the drive and path where the
"personal directory" and files it contains are located. If a file listed
in the directory is not found here, the download drives will then be
searched, so it is not necessary to have a copy of a file here in order to
be personally downloadable. However, the download directory must be here.
Parameter 142 allows the directory and/or files that are personally
downloadable not to be accessible through the normal download, if desired.
The "personal directory" is utilized by the P)ersonal download command in
the files section of RBBS-PC. It differs from D)ownload in that
(a) only files listed in the directory can be downloaded
versus any file that exists,
(b) the time to download is not checked against the time
remaining, so that the file can be downloaded regardless
of how little session time remains,
(c) the files downloadable can be constrained to match any
field in the user's record (e.g. limited by caller's name
so that file is addressed specifically to the caller),
(d) the download can be constrained by security level.
Parameter 143 allows the SYSOP to provide the name of the "personal
directory" -- the default name is "PRIV". If no extension is specified,
".DEF" will be used. The personal directory has a different format from
the other directory files. It has a one-character field after the file
description used to mark whether file has been downloaded. This is
followed by the field that matches the user record (or has a security level
if the first character of the field is blank).
Parameter 144 is a way of specifying the default protocol to be used when
downloading personal files using the "P" command in the file subsystem. If
no protocol is specified, the "P" command behaves exactly same as the
D)ownload command. If a protocol is specified, it will be used unless
overridden by the command line (i.e. "P;test;y").
Parameter 145 specifies the name of the file that contains a list of file
names that CANNOT BE DOWNLOADED (even if they are on the disks that
are available for downloading) unless the user supplies a password and/or
is at a specific security level. If you want to have no file security
at all, just put no file names in this file. If you include a password
with a file name all users (including one with SYSOP privileges) must be
able to give the password in order to download the file. For a more
detailed description of this file and how it works, see the section
entitled "How to Implement the Security for Download Files."
Parameter 146 specifies the file name which contains the privileged
group passwords that allow users to change temporarily their security,
time on the system, etc. -- if the SYSOP has set it up that way.
Callers shift to a group password by changing passwords. If the
password they select is found in the file containing the privileged
passwords, their private logon password is unchanged and they receive the
security level and/or time limit associated with the group password. If you
have no group passwords, just put nothing in this file. For a more
detailed description of this file and how it works, see the section
entitled "How to Implement the Password File."
Parameter 147 provides the SYSOP with the mechanism to allow users to
RBBS-PC CPC17-2A Page 120
download multiple files using the ASCII protocol (i.e. no error checking)
without any pausing or messages between files. This is particular useful
if the SYSOP wants users to download to a continuous feed printer.
Parameter 148 specifies the minimum security a user must have in order to
be able to "categorize" uploads when the SYSOP is using the File Management
System (FMS). Not all callers who upload files may categorize them in the
way that the SYSOP wants.
Parameter 149 controls who can view new uploads based on security level.
If the upload directory is not also the FMS directory, it is only viewable
by those who have a sufficient security level. If the upload directory is
the FMS directory, the entries with the default categories will be viewable
only if a caller has a security level equal to or greater than that
specified in parameter 149 (all other categories are viewable).
Parameter 150 specifies the security level of those users who will not be
shown the "epilogue" questionnaire. Typically the "epilogue" questionnaire
asks users questions or invites them to register. Once they have done so,
the SYSOP can have their security increased to this value either
automatically (i.e. via the questionnaire's script) or manually such that
the users no longer see the "epilogue" when they sign off.
Parameter 151 is the security level required to automatically add a user to
a SEMI-PRIVATE "conference". This parameter can only be activated when
CONFIG is in "conference maintenance" mode (see parameter 167). Each
message file has a security level associated with it which is the MINIMUM
SECURITY for a user to join it if the user is not in that conference's
USERS file. Callers with the minimum security level specified in parameter
151 are automatically added to the USERS file associated with that
conference if they are not there.
RBBS-PC's "auto-add" security feature permits SEMI-PRIVATE conferences,
that are open to callers with a certain security level. The "auto-add"
capabilities of RBBS-PC makes it possible for SYSOPs to have non-public
conferences without having to add each desired caller to the user's file.
A public conference is one whose "auto add" security level is no higher
than the default security and whose USERS file is the same as the main
message base's. This has the advantage of saving disk space (i.e. there is
only a single USERS file) but the disadvantage of not remembering the last
message read by the user in each conference.
A totally PRIVATE conference is one that is limited to persons already in
the USERS file associated with that conference and is created by making the
"auto add" security level higher than any caller's security.
RBBS-PC CPC17-2A Page 121
A SEMI-PRIVATE conference is one that has it's own USERS and welcome file
and whose "auto add" security level is set at an intermediate level that
some callers have and some do not.
As an example, if a conference is to be totally public but the user's last
message read, preferences, and security level in the conference are to be
remembered,
1. set the security level required to automatically add a user to the
conference equal to the CONFIG utility parameter 124 (the default security
level for new callers), and
2. create a user's file for the conference.
All callers can join, and each user is automatically added to the
conference's USER file as they join the conference.
If you want a conference to be SEMI-PRIVATE set the security level to be
"auto add"ed to the conference higher than the default security level for
your system and only those users who have the security level specified in
parameter 151 can join the conference.
Parameter 152 is the minimum security level for a caller to "turbo logon".
It only applies to callers that have called your RBBS-PC system at least
once. It can be used to bypass everything when a user logs on (bulletins,
welcomes, etc.) and go directly to the either the main RBBS-PC menu or
directly to a conference. It only can be utilized when doing a single line
log on and by following your password with an exclamation point. The
"single line" logon has the format:
first name; last name; password;!conference name
As an example, a user named "Jon Smith" who called back for the second time
and had a password of "swift" who had been assigned a security level that
permitted "turbo logon" privileges who wanted to go directly to the
conference "RBBS-PC" could log on with the following sequence:
jon;smith;swift;!rbbs-pc
Parameter 153 is the minimum security required by a caller to add a
directory entry for an existing file. Typically this is restricted to the
SYSOP only.
Parameter 154 is the name of the help file that is automatically shown (if
the file exists) to a caller whenever the caller incurs a security
violation. It is an ideal candidate for using RBBS-PC's personalized
"smart" text file capabilities as described in section 8.9.
.ix Parameter 155
Parameter 155 allows the SYSOP to deny callers access to two of RBBS-PC's
"premium features -- DOORS and file downloading (either or both), for a
specific period of time.
One of the two purposes of RBBS-PC is to foster the free exchange of
information. Many SYSOPs would like to encourage new callers to read
bulletins and look at messages when they initially logon. One approach is
to simply restrict new users from all of the other RBBS-PC features using
RBBS-PC's extensive security system. RBBS-PC provides an intermediate
solution by allowing a SYSOP to require a user to be on-line for a specific
amount of time within a session before DOORS or file DOWNLOADS, premium
features are available to a caller.
RBBS-PC CPC17-2A Page 122
This feature is implemented by both activating CONFIG parameter 155 and
setting up the PASSWRDS file appropriately, see section 16.3.
For each level in the PASSWRDS file, a parameter specifies how many SECONDS
the caller must have used before the premium features are available. If a
caller tries to use a locked feature before the time has elapsed, the
caller will be given a message and denied access. This is *NOT* recorded
as a security violation. See section 16.3 for a more detailed description
of how to implement this feature in the PASSWRDS file.
The file TIMELOCK.HLP should be placed with the other RBBS-PC HELP files.
This file (if found) will be shown to a user who is locked out of a
command. If the TIMELOCK.HLP file is not available, the caller will be
given a "canned" message: "Sorry, (name), try that function later." The
example TIMELOCK.HLP uses SMART TEXT. If SMART TEXT is not implemented
with control code (123), the file TIMELOCK.HLP should be modified as
appropriate.
Parameter 156 is the security level of a caller in a "sub-board" or
"conference" who will have their security level automatically reflect
whatever the security level they are assigned in the main USERS file. This
means that on large RBBS-PC's with many "sub-boards" and "private
conferences" the SYSOP does not have to update each caller's USER record in
the many different USER's files. The SYSOP need only change the caller's
USER record in the main USER file and it will be reflected in any "sub-
board" or "conference" that the caller joins.
Parameter 157 is the minimum security a caller must have to be able to read
and kill all messages (in the message base for which this is a .DEF file).
A SYSOP of a "sub-board" no longer need be given full SYSOP privileges when
the SYSOP just needs to be able to review and monitor all mail.
If a message record begins with an ASCII value of 1, it will not be
displayed to the caller. Parameter 158 allows the SYSOP to specify any
character string IN ADDITION to this that RBBS-PC is to use as a criteria
for not displaying a record in the message file. The default value is
"SEEN-BY:".
RBBS-PC CPC17-2A Page 123
11.9 Parameters for Multiple RBBS-PC's/Conferences
--------------------------------------------------
RBBS-PC allows multiple RBBS-PC's to run in the same environment/network
and share many of the same files. If you ever plan to do this or if you
are going to do this, set this number to the MAXIMUM number you ever
envision running. Up to 36 RBBS-PC's can share the same files. Different
environments have different maximum number of nodes that they can
effectively support. Parameter 161 allows you to specify the maximum
number of RBBS-PC's that the MESSAGES file should be initialized for.
Parameter 162 allows the SYSOP to designate the type of environment that
multiple copies of RBBS-PC will be sharing files in. This is necessary so
that RBBS-PC can use the mechanism that is appropriate to the specific
environment when sharing files. RBBS-PC currently can handle the following
environments for multiple RBBS-PC's:
1. MultiLink (The Software Link, Inc.)
2. OmniNet (Corvus)
3. PC-Net (Orchid)
4. DESQview (Quarterdeck Office Systems)
5. 10 Net (Fox Research using 3COM interface)
6. IBM's NETBIOS
NOTE: Many manufacturers utilize Orchid's network conventions. As an
example, AST and Alloy are both vendor's whose "network" is .EXE file-
compatible with Orchid's. If you have a network of PC's, check with the
vendor to see how compatible their network is with those supported by RBBS-
PC.
Some local area network environments are not designed to have applications
constantly branch back to the beginning and re-open already open files. If
you are in this environment or simply want to run external programs after a
user logs off or RBBS-PC recycles, parameter 163 allows you to elect to do
this. If you specify "internal", RBBS-PC will function as it currently
does and branch back to its beginning. If you specify "system", RBBS-PC
will exit to DOS and (if you are running RBBS-PC out of a .BAT file) you
can then automatically invoke any other "housekeeping" programs you want
before re-invoking RBBS-PC. It should be noted that this will add a
considerably delay to RBBS-PC's recycling time as RBBS-PC will have to
reloaded back into memory every time it recycles.
Like the MESSAGES file, the USERS file must also be static in length for
RBBS-PC. Parameter 164 allows the SYSOP to set the size of the USERS file.
RBBS-PC automatically keeps track of the records available for use in this
file and does the necessary "housekeeping." To do this RBBS-PC requires
the USERS file size (i.e. the number of records in it) to be a power of 2.
When the USERS file get full (i.e. all its records are used up) and the
SYSOP neither "packs" it nor increases the size of the file, no new users
will be able to be added to the users until one of these two events occurs.
Parameter 291 lets new users get on even if the users file is full.
RBBS-PC requires that the "Messages" file be static in length. It
automatically keeps track of the next record available and does the
necessary housekeeping to maintain the integrity of the file. Parameter 165
allows the SYSOP to set the size of this file. CONFIG.BAS will
automatically determine what size the current file is and will reformat a
pre-CPC12-3A MESSAGES file if it finds one. If you do not increase the
size of your existing MESSAGES file, no one will be able to leave any new
messages. Similarly, when the MESSAGES file get full (i.e. all its records
are used up) and the SYSOP neither "packs" it nor increases the size of the
RBBS-PC CPC17-2A Page 124
file, no one will be able to leave a message until one of these two events
occurs.
The minimum size of the MESSAGES file is equal to 1 (The "checkpoint"
record) plus the maximum number of concurrent RBBS-PC's ("node" records)
plus the maximum number of messages allowed multiplied by 5 (each messages
is assumed to average five 128-byte records)
Therefore, if parameter 161 of CONFIG where 12 and parameter 165 of CONFIG
where 50, the minimum number of records that could be specified for
parameter 125 would be
1 (The "checkpoint record)
+ 12 (The number of "node" records)
+250 (50 messages x 5 128-byte records each)
----
263 records for the MESSAGES file
Parameter 166 lets you set the maximum number of messages that the SYSOP
will allow on the system at any one time. The number will have to be
based on the size of the average message on your bulletin board. Most
messages require about 600 bytes on the average. The absolute upper
limit on the number of messages is 999. If you specify 250 messages,
you can expect that the MESSAGES file will be formatted to more than 160K
in size.
Parameter 167 allows "conference" files to be maintained. A "conference"
consists of a message file and, if a "private" or "semi-private"
conference, a corresponding users file. The name of the conference can be
anything that the SYSOP selects but can not be longer than 7 characters.
The message file's name for a conference consists of the conference name
plus the characters "M.DEF". The user file's name associated with
"private" conferences consists of the conference name plus the characters
"U.DEF".
Parameter 167 allows the SYSOP to create, expand, or contract either or
both of the files associated with a "conference." This occurs ONLY when
the SYSOP "ENDs" the CONFIG session by pressing the key marked END.
Parameter 167 allows the SYSOP to perform all the utility functions on page
10 of CONFIG on the conference that was named/selected with parameter 167.
To make a "private" conference "semi-private", see the discussion under
parameter 151. For a further discussion of "conferences" see sections 18
and 19.
Parameter 168 is the file extension to be automatically added to the name
of any uploaded file that has no extension specified by the caller. RBBS-
PC will not permit a file to be uploaded if the file name being uploaded
already exists but has the default extension. As an example if a caller
attempted to upload TEST.ARC and
1. the file TEST.ZIP existed and
2. parameter 168 specified ZIP, then
the caller would be told that a duplicate file existed.
Parameter 169 allows the MESSAGE files to "grow." The need for having a
pre-allocated MESSAGE file was dictated by the limitations of the Corvus
Network software. Since none of the other networks supported by RBBS-PC
have this limitation, parameter 169 allows a SYSOP to setup a nominal
message file (say 500 records) and allow it to grow as user's leave
RBBS-PC CPC17-2A Page 125
messages.
RBBS-PC CPC17-2A Page 126
11.10 RBBS-PC SYSOP Utilities
-----------------------------
The message file contains all messages for the RBBS-PC system. As
messages are killed they are only flagged as inactive. Parameter 181
should be used periodically to recover the space occupied by the killed
messages. After completion, only the text of active messages will be
present and the old file will remain on the system with the qualifier of
".OLD". Also, you will need enough free disk space for a second copy of
the messages file (with a qualifier of ".BAK") when packing a message file
or the packing cannot be performed. If enough space is not found the
packing will terminate abnormally and the message file will be recovered.
Parameter 182 removes deleted users and users who have not been on the
system within the number of months specified using parameter 16 in CONFIG.
You should have enough free disk space for a second copy of the users
file (with a qualifier of ".BAK") or the rebuilding will terminate
abnormally (the users file will be restored). It is important to note that
beginning with CPC12-5A, users files are no longer a random file that is
accessed sequentially but now is a random file that is accessed directly.
When a user logs on to RBBS-PC or joins a "conference", RBBS-PC "hashes"
the users name to find the users record directly. That is why every users
file's size is a power of 2 (i.e. 256, 1024, etc.). This allows users to
log on much more quickly to RBBS-PC's that have a very large number of
users.
Parameter 183 will display the message headers of all messages, active
and killed, that are present in the message file. This is left over from
one of the many "debugging" stages of RBBS-PC prior to CPC09. Following
the policy of making all changes "additive", this function has been
retained. It may help some SYSOPs recover from disk hardware failures.
Parameter 184 permits messages to be renumbered sequentially starting
from a specified message using whatever starting number you wish.
Please note that there is not much error checking to be sure that the new
numbers do not duplicate those of lower numbered active messages. When
complete, the next message to be created will be the next higher number
from the resequence. Unpredictable results will occur if a SYSOP creates
messages with duplicate numbers!
Parameter 185 goes through the current message file and reconstructs the
chains that link the messages together. Message files that have "blank"
messages or abbreviated messages (i.e. some lines of text are missing) can
be repaired with this facility.
Parameter 186 allows the SYSOP to require all users (old and new) to answer
the required questionnaire whose name was specified in parameter 82.
Parameter 187 allows the SYSOP to determine whether the format of the RBBS-
PC directory of files being used by the RBBS-PC File Management System
(FMS) conform to the exact fixed format required by the FMS (in case the
text editor used by the SYSOP to edit the file inserted tabs or shorten
lines that had trailing blanks at the end of them).
RBBS-PC CPC17-2A Page 127
Parameter 188 allows the SYSOP to determine whether the format of the
personal downloads directory is in the proper format for a single FMS.
Parameter 189 is a utility that will guide a new SYSOP, sequentially,
through the parameters that would normally have to be changed when setting
up a new RBBS-PC.
Parameter 190 is a utility that will guide a SYSOP, sequentially, through
the parameters that are new and/or changed for the current release of RBBS-
PC.
Parameter 191 is a utility that will turn the "printer enabled" flag off in
all the node records. This is useful if somehow the printer is
accidentally enabled when no printer is available because the code
generated by the BASIC compiler doesn't recover from this condition.
Parameter 192 allows the SYSOP to select how "highlighting" of text will be
treated. This prevents users who have not elected to have color graphics
from seeing meaningless data imbedded in the displayed text. Putting in
nothing disables color prompts and highlighting of search strings. For a
more complete explanation of RBBS-PC's display of colors to callers in text
files see section 8.10.
RBBS-PC CPC17-2A Page 128
11.11 RBBS-PC's File Management System Parameters
-------------------------------------------------
Parameter 201 specifies the letter of the single drive available to
this copy of RBBS-PC to which uploaded files can be written. When a file is
uploaded, the file specified by CONFIG parameter 202 will be automatically
appended with the file name, file size, date of upload, and short
description as specified by the user.
Parameter 202 of the CONFIG program asks for the name of the text file
to be used as an RBBS-PC "directory" of files into which the file name,
file size, and file description of uploaded files can be recorded. The
default name is 99.DIR and it must be on the drive/path specified in
parameter 203.
Parameter 203 specifies the drive/path were the upload directory is to be
found.
Parameter 204 specifies the letters of the drives from which files can be
downloaded. The order in which they are specified is the order in which
the drives will be searched. If the order is BAC, then drive B will be
searched first for the file, then drive A, and finally drive C. While
there can be duplicate files on each of the drives, the first file found
will be the one downloaded to the user.
Parameter 205 allows the SYSOP to indicate that DOS subdirectories are to
be used by allowing the number of DOS subdirectories to be used for
downloading to be specified (0 to 9999). This number is equal to the
number of DOS subdirectories to be used for uploading (0 or 1) plus the
number of DOS subdirectories to be used for downloading.
Parameter 206 allows the SYSOP to indicate the DOS subdirectory to which
uploads are to be written. RBBS-PC will prepend the upload disk drive to
it (see parameter 201) and append the upload file name after it when
uploads are written to disk.
Parameter 207 allows the SYSOP to indicate that DOS subdirectories are to
be used when searching for files on downloading. A valid download drive
followed by a colon, a reverse backslash, and the subdirectory name that is
to be searched must be entered. If the root directory is also to be
searched, just enter a valid download drive followed by a colon. Each
download disk drive is searched for only those subdirectories that were
specified as existing on that specific drive. If two download DOS
subdirectories are specified (A:\TEST1 and B:\TEST2) and two download disk
drives for parameter 204 (A and B), the search for a download file will be
in the following order:
A:\TEST1\filename
B:\TEST2\filename
It is possible to have the same subdirectory name on different download
drives. Each would have to be individually specified (A:\GAMES and
B:\GAMES If they where, the search for a download file would be as
follows:
A:\GAMES\filename
B:\GAMES\filename
Parameter 208 is only functional if you have responded "Yes" to either
parameter 206 or parameter 207. This parameter allows the SYSOP to list,
change, add, or delete the DOS subdirectories to be used for either
RBBS-PC CPC17-2A Page 129
uploading (parameter 206) or downloading (parameter 207). CONFIG does NOT
actually create or delete such DOS subdirectories -- that's up to the SYSOP
to do using the standard DOS commands. Parameter 208 simply allows the
SYSOP to identify which DOS subdirectories will (or may) exist when RBBS-PC
is running.
Parameter 209 allows the SYSOP to specify the extension that RBBS-PC's
"directories" of files are to have. See section 13 for a description of
RBBS-PC's "directories" of files.-- they have no relation to DOS 2.x and
above subdirectories! Most SYSOPs categorize the files that are available
for downloading into general groups (games, utilities, etc.). The default
is "DIR".
Parameter 210 specifies the alternative extension to be used for
"directory" files. The main use for an "alternate" extension is to allow
"sub-boards" to share directories using the main extension (parameter 209),
but also have some directories unique to the "sub-board" that are not
shared with others.
The name of the directory of directories is specified in parameter 211.
This allows sub-boards with the same extension to have a different
directories of directories. The main RBBS-PC system might have a directory
of directories named MAIN.DIR where parameter 211 was "MAIN" and parameter
209 was "DIR". A sub-board might have a directory of directories named
BETA.DIR where parameter 211 was "BETA" and parameter 209 was "DIR".
Parameter 212 allows the SYSOP to exclude the primary directory (DIR.DIR)
from the search done by the New command. If you have multiple
directories (i.e. RBBS.DIR through BASIC.DIR), any dates in the
primary directory would not be of files. The "New" command (as in
"What new files have been put on the download directories since I was
last on?") search each line of each file whose extension is DIR for a
date field. Since the first level directory is normally a listing of the
other directories and their general subject areas, it is advisable to omit
the first level directory from the "New" command.
Descriptions of files uploaded are always appended to the upload directory.
Parameter 213 allows the description to be appended to another file. This
could be, for example, a list of all files on the system, or the basis for
a bulletin reviewing the uploads.
Parameter 214 is how the SYSOP declares that there is a shared, single FMS
directory. Leave it blank if there is none. Section 13 discusses in
detail the advantages of using this directory, which has a different
structure from other directory files. This file must be in the drive/path
for directories.
RBBS-PC CPC17-2A Page 130
Users who upload can classify uploads into a category if their security is
at least as high as the level specified in parameter 148. This option can
save the SYSOP considerable time. If the uploader cannot classify the
upload, it goes only to the upload directory and uses the default category
code if written to the FMS directory.
If you do NOT want users to categorize the files that they upload,
independent of whether or not you are using FMS, simply set the CONFIG
parameter 148 to a security level higher than any user can obtain. If the
uploader cannot classify the upload, it goes only to the upload directory
and uses the default category code if written to the FMS directory.
If you DO want users to categorize the files that they upload you must
follow these four steps:
1. Set CONFIG parameter 148 to the security level of the U>pload
command.
2. Create a help file to show users when they are asked to categorize
an uploaded file that might look something like:
Category Category Description
Code Name
1 Utilities General Utilities
2 Games Games
3 RBBS-PC RBBS-PC files
4 RBBS-UTIL Utilities for RBBS-PC
3. Set CONFIG parameter 67 to the name of the file that you created
for step 2
4. If, and ONLY if, you are using the FMS, create a second file in
the format described in section 13.4 for parameter 217 and set parameter
217 to the name of the file created in this format.
Set parameter 215 to "YES" if there are no directories other than the FMS
directory. That increases the speed of RBBS-PC because it does not look
for additional directories. If you do not have a shared directory or have
a hybrid system with some physically distinct directory files, set this
parameter to "NO".
Parameter 216 is the default category code for uploads. This parameter is
how uploads get classified in the FMS directory if the uploader cannot
provide a classification. To make all new uploads private and viewable
only by the SYSOP (until the SYSOP reviews the files and changes the
classification), set the default code to "***". The default is "UNC" for
UNClassified.
Parameter 217 is the name of the text file which tells RBBS-PC what
categories are included in the shared FMS directory. The format of the
file is described in section 13.5.
Parameter 218 allows the SYSOP to restrict searches (either for specific
strings or via the "N>ew" command by date) to a single RBBS-PC directory of
files. If not restricted, all RBBS-PC file directories will be searched.
Parameter 219 sets the maximum length of the description that can be given
to an uploaded file. RBBS-PC can be configured so that those who upload
files can provide a description of the file they upload. This description
informs others what the file does and helps them decide whether they want
RBBS-PC CPC17-2A Page 131
to download the files. The maximum length of the description can be set
to any value between 40 and 46. WARNING: this option will not change the
length of existing directories.
Parameter 220 specifies where all directory files must be put, except
possibly for the upload directory. Only in this DOS directory does RBBS-PC
look for RBBS-PC directory files, with the sole exception of the upload
directory when the caller's security level permits the upload directory to
be viewed (see parameter 149).
RBBS-PC CPC17-2A Page 132
11.12 Communications Parameters (part 1)
----------------------------------------
Parameter # 221 requests the user to specify the communication port that
RBBS-PC will use. If you specify COM0, RBBS-PC will run on a PC without
using a communications port or modem and still appear to the PC user as if
they were accessing RBBS-PC remotely. This "workstation" feature can allow
RBBS-PC to be used in a local area network environment where each of up to
36 PC's can access the central RBBS-PC system (on the LAN server) and use
RBBS-PC for electronic mail within the LAN. Alternatively this
"workstation" mode can be used to teach users how to access RBBS-PC in a
classroom environment without requiring telephone access.
The BASIC language can only support COM1 and COM2, and when either of these
are selected and you specify that you will not be using a "FOSSIL" driver,
RBBS-PC will use the built-in BASIC support for remote access (i.e. via a
communications port and a modem).
However, RBBS-PC will interface with "FOSSIL" drivers that support not only
COM1 and COM2 but also COM3 through COM8. If you use parameter 221 to
indicate that RBBS-PC is to access the communication port via a FOSSIL
driver, the FOSSIL interface (FOSSCOMM.OBJ) written by Daan Van der Weide
will be used. FOSSCOMM.OBJ provides access to whatever FOSSIL drivers that
are installed on the PC running RBBS-PC. In a multi-tasking environment
such as DESQview up to 8 copies of RBBS-PC can run simultaneously accessing
COM1 to COM8, respectively, using Ray Gwinn's X00.SYS device driver. Ray
can be reached via FidoNet (109/639) or the RENEX bulletin board at (703)
494-8331 or (703) 690-7950.
Parameter 222 allows the SYSOP to specify the number of seconds that RBBS-
PC should wait after initializing the modem with a "reset" command. Most
modems require only 2 seconds, however some may require much (MUCH) longer.
If the 2 second default is not sufficient consult with your modem vendor
and try different settings.
Parameter 223 allows the SYSOP to specify how long to wait prior to issuing
a modem command. This is most useful when you have configured RBBS-PC to
only issue commands between rings and want the modem to "settle down" after
a ring has ended. The default setting is one second. If you find that
2400 baud calls are improperly connected at 1200 baud, increase the wait.
Some modems take longer to connect at 2400 than at lower speeds.
Parameter 224 specifies the number of rings to wait before answering the
phone. Specifying zero rings means that the modem (not RBBS-PC!) will
answer the phone as soon as it rings.
If you specify the number ONE, RBBS-PC will wait for the phone to ring and
then instruct the modem to answer the phone. This is the default setting
and requires that the modem be capable of indicating to RBBS-PC that the
phone is ringing -- either providing the "ring indicator" signal via a
modem cable that has PIN 22 connected at both ends OR by sending the
characters "RING" each time the phone rings.
Specifying a number equal to ZERO (and not specifying "ring-back") means
that RBBS-PC will initialize the modem to automatically answer the phone
(independent of RBBS-PC) and RBBS-PC will simply wait for carrier detect to
occur. This is NOT RECOMMENDED. However, if your non-Hayes modem simply
is incapable of indicating that the phone is ringing or your modem cable
does not have PIN 22 connected, this is the option you will have to elect.
If this option is selected, you will be reminded that you are shooting
yourself in the foot by allowing exiting to DOS remotely (either through a
RBBS-PC CPC17-2A Page 133
"door" or via the SYSOP function 7) when activating "doors" in parameter
101. This is because in this mode (the modem answering the phone and NOT
RBBS-PC), if you were inadvertently disconnected while in DOS or in a
"door", the next person to dial your system would be connected to wherever
you were because the modem (not RBBS-PC) is answering the phone.
If you specify a number greater than 2 means that RBBS-PC will either:
1. wait until the specified number of rings to answer the phone, or
2. answer the next call after the current one after the specified
number of rings specified provided that the next call comes
within 45 seconds after the first call stops ringing the phone.
This mode is called RING-BACK.
Specifying a number greater than one is useful only when a single phone
line can receive both voice (i.e. callers who wish to speak with the SYSOP)
and data calls (i.e. for RBBS-PC) on an unscheduled basis. In this type of
environment (i.e. a random mix of voice and RBBS-PC calls), there are two
ways a SYSOP can set up RBBS-PC so that RBBS-PC can automatically determine
if the call is for the SYSOP or for RBBS-PC.
First, the SYSOP can establish the rule with the callers that if unable to
personally answer the phone, then RBBS-PC will answer the phone after it
rings the number of times specified in parameter 224. Callers can let the
phone ring and (if it is not answered by a person within some agreed upon
number rings) know that it will be answered by RBBS-PC. This is useful to
those who may have either hearing or speech problems and are unable to use
the telephone conveniently for voice communications.
A second approach is the more classic, "ring-back" approach. RBBS-PC can
be told to NEVER answer the first call (it can ring forever!). However,
should the caller WAIT A MINIMUM OF 12 SECONDS (a Hayes restriction) and
call back no later than 45 seconds after the last ring of the first call,
RBBS-PC will answer the call after the number of rings indicated in
parameter 224 provided that the number of rings is set to between one and
five. If callers want to make a voice contact, they can simply call and let
the phone ring until it is answered. If you have a dedicated line for your
RBBS-PC (either full-time or on a scheduled basis), parameter 224 should
be set to ZERO.
Parameter 225 provides the SYSOP with the capability of selecting ANY modem
commands appropriate for the modem being used -- not just the default Hayes
commands RBBS-PC would normally use. Before the default RBBS-PC standard
Hayes commands are changed, you should thoroughly understand the modem that
your are using and the modem commands, as used by RBBS-PC, that are
described in section 12.
Parameter 226 allows the software-based MNP to be optional within RBBS-PC.
REGRETTABLY, this option can not be selected with version CPC17-2A. This
is because it was not possible to resolve the linkage incompatibilities
between the new compilers and the MNP library and RBBS-PC interface prior
to the release of CPC17-2A. Every effort is being made to correct this
particular problem. However, RBBS-PC does support MNP protocol that is
hardware-based (i.e. built into the calling and answering modems).
Some SYSOPs may not wish to provide their users with the choice of MNP
protocol (especially if they are employed by a company that has a competing
protocol). RBBS-PC's features and growth are designed to be "additive."
This parameter allows each SYSOP to decide if MNP protocol is to be
RBBS-PC CPC17-2A Page 134
available for file transfers. Microcom's error-free protocol, MNP, has
been available for file transfer beginning with version CPC12-4A of RBBS-
PC.
Parameter 227 allows the SYSOP to tell RBBS-PC either to wait to issue
commands in-between rings or to issue modem commands without waiting. Some
modems cannot both handle the telephone ringing and accept modem commands
simultaneously. Other modems, like the Hayes, can handle such simultaneous
demands. For these later (i.e. Hayes, Prometheus, Multi-Tech, etc.) this
option should be set to "NO."
Some 2400 baud modems (like the Hayes) MUST be opened initially at 2400
baud because when they automatically answer the phone they can only "bump
down" when automatically detecting baud rate (i.e. from 2400 down to 1200
down to 300). Parameter 228 allows the SYSOP to select the baud rate at
which RBBS-PC is to open the modem at initially.
The SYSOP can select the number of seconds RBBS-PC will allow a user to be
"idle" (i.e. not sending or receiving data) via parameter 229. Before a
user is logged off, a warning message is issued. If the caller remains
idle for the following 30 seconds the caller is automatically logged off.
Parameter 230 allows the SYSOP to indicate if a "dumb" modem is being used
(i.e. one that will answer the phone and automatically detect the caller's
baud rate if it is the modem was opened for). Selecting this means that no
modem commands are written to the modem.
If the SYSOP has a non-Hayes modem (i.e. one that will not recognize Hayes
commands and will not return Hayes responses) that will only "auto-answer"
the phone, parameter 230 allows the SYSOP to so indicate to RBBS-PC by
selecting "dumb" modem. Typically this would be some communications
network (i.e. TymnNet) or local area network that supplied a simple RS-232
interface. Selecting this option causes RBBS-PC to
1. Issue no Hayes commands,
2. Depend on no Hayes-like responses,
3. Control the interface with the Data Terminal Ready (DTR),
4. Assume somebody has called whenever Carrier Detect (CD) is
detected, and
5. Assume that whomever calls is at the baud rate selected in
CONFIG parameter 228.
The Hayes 2400 baud modem has no hardware switches. It's remembered,
permanent settings can be set only through software. Parameter 231 will
properly initialize a Hayes 2400 modem for use with RBBS-PC.
Parameter 232 is the time to wait after dropping DTR. This is used in
RBBS-PC for dropping the connection after a caller logs off normally. Too
short a delay will cause the modem not to re-initialize properly. The
default time is 3 seconds.
In order to provide the maximum flexibility (and get RBBS-PC out of the
protocol writing business), RBBS-PC supports external protocol drivers via
a standard interface. The external protocol driver for YMODEM, YMODEMG,
IMODEM is the file QMXFER.EXE. The external protocol driver for WINDOWED
XMODEM is WXMODEM.EXE. The external protocol driver for KERMIT is
PCKERMIT.EXE. These protocols work only if the external drivers are
available and defined in the file specified by parameter 233. Also see
sections 21.1 and 22.2 on how these drivers are invoked.
RBBS-PC CPC17-2A Page 135
RBBS-PC can check right after a caller logs on whether the caller's
communication program supports autodownload. Turning on parameter 234
means that RBBS-PC will always do this check. However, this check is
incompatible with some terminals and communications packages, causing them
to stop displaying on the local screen. If the check is passed, RBBS-PC
announces that autodownload is available and asks callers if they want to
use it. This check is unnecessary for autodownload to work. The caller
can control whether autodownload is used with the T)oggle command in
utilities. It is recommended that this option NOT be enabled.
Parameter 235 allows the SYSOP to tell RBBS-PC that files ending in binary
file extensions (i.e. .ARC, .EXE, .COM, .OBJ, .WKS, .BAS, or whose
second letter of the extension is Q) can not be downloaded unless the user
selects a non-ASCII protocol. This should eliminate some user problems
before they occur. IBM's BASIC interpreter's SAVE command default is
to write files in a special binary format (also referred to as
'tokenized') because they require much less disk space.
Parameter 236 allows a SYSOP to use some of the "less than perfect" modems
that have a tendency to "go to sleep" under rigorous usage. Setting this
parameter to a non-zero value, means that RBBS-PC will re-cycle if no calls
are received after the specified non-zero value number of minutes. When
re-cycling RBBS-PC resets the modem -- hence "wakes it up" if it has gone
to sleep. A setting of 10 minutes is recommended for busy lines and 60
minutes for less busy lines. Specifying 0 means that RBBS-PC will not re-
cycle if no calls are received, but simply wait for the next caller.
Parameter 237 allows the SYSOP to leave the modem at the baud rate it was
initially opened at rather than automatically matching the baud rate of the
caller. RBBS-PC normally changes the baud rate in the RS-232 interface to
match that of the callers. Some modems will match the baud rate of the
incoming caller and allow the PC to continue communicating with it at the
baud rate the modem was opened at (the modem buffers it down to the callers
baud). Some 9600 baud modems will allow the PC that they are connected
with to transfer data to them at 19,200 baud and the modem will talk to the
caller at whatever the baud rate of the incoming callers modem is set at.
RBBS-PC CPC17-2A Page 136
11.13 Communications Parameters (part 2)
----------------------------------------
Some of the less sophisticated communications packages automatically switch
back to their original communications parameters for parity, data bits, and
stop bits if the user manually changes them during the session. Similarly
some of the older public data networks can't talk to a terminal that is set
at N/8/1. As all error-free protocols typically require the settings for
these to be N/8/1 (i.e. no parity, eight data bits, and one stop bit),
parameter 241 allows the SYSOP to have RBBS-PC accommodate these more
primitive environments by automatically switching back to the original
parameters after the file transfer is complete.
Parameter 242 allows a SYSOP to decline calls from new callers based on the
baud rate specified.
Some SYSOPs believe that 300 BAUD users have a "pre-puberty" mentality and
cause more problems (i.e. infantile messages) for the SYSOP than their
contributions justify. Another reason for denying access to 300 BAUD
users is when RBBS-PC is running in a multi-tasking DOS environment that
does not handle 300 BAUD very efficiently (i.e. like MultiLink). While
RBBS-PC is intended to be as open a system as possible, each SYSOP has the
option of electing to accept calls of only a certain baud rate or higher
for new callers. Whatever reasons a SYSOP has for denying access to 300
BAUD users, this option enables the SYSOP to select to do so using CONFIG
rather than having to modify the RBBS-PC source code.
Parameter 243 allows RBBS-PC to be configured to allow registered users to
logon at any baud rate baud even if new users can't.
Parameter 244 allows modems that require it, to have "flow control" between
the modem and the PC running RBBS-PC using the "clear-to-send" signal, RTS.
Some modems with built-in error checking protocols require this to be set
on or, should an error-free link become disconnected, the modem will never
respond to the PC after RBBS-PC recycles.
Parameter 245 allows another method of "flow control" between the modem and
the PC running RBBS-PC -- XON/XOFF. Since RBBS-PC attempts to write to the
caller as fast as possible, XON/XOFF flow control is normally turned off --
unless parameter 245 has enabled it. When RBBS-PC is attached to a public
data network, it can be sometimes necessary to use this method of "flow
control" rather than "clear-to-send". Setting this parameter to "yes"
means that RBBS-PC will universally support XON/XOFF. However the XON/XOFF
check is only made after the buffer is emptied as specified in parameter
54. It is recommended, when XON/XOFF flow control is going to be used,
that parameter 54 be set to 32 bytes so RBBS-PC can be as responsive as
possible.
Parameter 246 specifies the maximum time to wait for carrier after RBBS-PC
answers the phone. Some of the "less than perfect" modems disconnect
immediately and RBBS-PC would stay "off the hook" long enough to receive
the automated voice message requesting the modem to "hang up and please
dial again."
RBBS-PC CPC17-2A Page 137
11.14 Parameters for RBBS-PC NET-MAIL
-------------------------------------
Parameter 261 allows the SYSOP to specify the time of day in HHMM format
after which RBBS-PC is to exit after creating a dummy file called
RBBSxTM.DEF where "x" is the node ID of the node that EXITed to DOS. By
adding two "IF" statements to the simple .BAT file described in Section 14,
the RBBS-PC-created file RBBSxTM.BAT will be invoked if RBBS-PC is invoked
with the following .BAT file (assuming "x" = node id = 1):
IF EXIST C:RBBS1F1.DEF DEL C:RBBS1F1.DEF ' Delete SYSOP F1 semaphore
IF EXIST C:RBBS1TM.DEF DEL C:RBBS1TM.DEF ' Delete Time/drop semaphore
IF EXIST C:RCTTY1.BAT DEL C:RCTTY1.BAT ' Delete batch file for DOOR exit
RBBS-PC.EXE 1 RBBS1PC.DEF ' Invoke RBBS-PC for node 1
IF EXIST C:RBBS1F1.DEF GOTO EXIT ' Check for SYSOP F1 key pressed
IF EXIST C:RBBS1TM.DEF C:RBBS1TM.BAT ' Check for Time to go to DOS
IF EXIST C:RCTTY1.BAT C:RCTTY.BAT ' Check for exit to a DOOR
C:RBBS.BAT ' Re-invoke RBBS-PC again
:EXIT
The above assumes that RBBS-PC node is "1", the name of the file that
invoked RBBS-PC is RBBS.BAT, and everything is in the same DOS subdirectory
on the "C" drive. Obviously, this example can be made more generic.
The file that RBBS-PC exits to is named RBBS1TM.BAT (but it could be named
anything that the SYSOP desired). It is the responsibility of the SYSOP to
name and create the RBBS1TM.BAT file. A simple such file that invoked Kim
Wells' utility MU-PURGE and then re-invoked RBBS-PC would contain the
following two statements:
MU-PURGE PURGE.CTL
RBBS.BAT
As always, .BAT files are limited only by the creativity of their authors.
Parameter 262 allows RBBS-PC to handle "store-and-forward" mail of messages
and files. Currently the only such "net mail" that is compatible with the
FIDO store-and-forward mail specification is supported such as FIDO, SeaDog
(see Appendix V) and BINKLEY TERM. By enabling this option, the SYSOP
assumes the responsibility of configuring the "net mail" application to
1. answer the phone and determine if the caller is sending "net mail".
2. if the caller is not sending "net mail", the net mail application
must invoke RBBS-PC with the following command line:
RBBS-PC.EXE nodeid filename /time /baud
where:
"nodeid" is the node ID in the range 1-9, 0, or A-Z.
"filename" is the fully qualified file name to use as the
RBBS-PC ".DEF" file.
"/time" is the time of day for RBBS-PC to return to the "net
mail" application that called RBBS-PC.
"/baud" if the baud rate that the caller dialed in at.
RBBS-PC CPC17-2A Page 138
Parameter 263 is intended to be used when RBBS-PC is connected to a public
data network (PDN) as a "node" -- not all systems that people log into on a
PDN need be "main frame" computers! When RBBS-PC is a node on a public
data network, typically the network will do the echoing -- between the
caller and the port he/she accesses on the PDN and between RBBS-PC and the
port RBBS-PC accesses on the PDN. This causes file transfers to be a
problem because the PDN will continue to echo. Therefore it is necessary
to be able to go into an "image" mode where data is passed through the PDN
intact with no echoing. The contents of this string is obviously dependent
on the predilections of the PDN that RBBS-PC is attached to. The string is
sent just before a file exchange occurs. Any character can be included in
the string using it's decimal ASCII equivalent simply by putting a number
inside square brackets. Characters not in square brackets will be
transmitted as they were entered. The string "a[32]" will be interpreted
as a lower case letter "a" followed by a blank.
Parameter 264 is intended for situations where RBBS-PC is a node on a PDN.
It is the string that sent following a file exchange that causes the PDN to
resume echoing. As with parameter 263, the contents of this string is
entirely dependent on the predilections of the PDN that RBBS-PC is attached
to.
Parameter 265 allows the SYSOP to specify the default mode of who echoes
characters back to the user. Normally RBBS-PC echoes each character that
the caller types back to them. An individual caller can set their
preference for who is doing the echoing in the Utilities subsystem within
RBBS-PC. Callers using telecommunications devices for the deaf (TDD's) or
using PDN's that do local echoing can dramatically improve their through
put by not having RBBS-PC echo characters back to them.
Parameter 266 allows the SYSOP to force RBBS-PC to acknowledge each line
uploaded via the ASCII file transfer with a character string. Typically,
an ASCII upload is characterized by two fundamental features -- it contains
no unprintable characters and it does not require any "error checking".
Under some circumstances a callers communications protocol may require a
response from RBBS-PC (i.e. a line feed) before the next line will be
transmitted.
RBBS-PC CPC17-2A Page 139
11.15 New Users Parameters
--------------------------
Parameter 281 allows the SYSOP to elect to not ask new users for their
default parameters. RBBS-PC typically asks new users whether their
terminal supports upper case, whether they want line feeds, what they want
for a graphics preference, what they want for a default protocol, and
whether they want "turbo-key". Sometimes these questions confuse new
users, who lack the knowledge to answer them. To bypass the questions and
force new users to get the defaults (upper and lower case, line feeds, no
graphics, no protocol, no nulls), specify "NO" this parameter.
Parameter 281, parameter 282, parameter 283, parameter 284, parameter 285,
parameter 286, parameter 287, parameter 288, and parameter 289 are not
implemented in RBBS-PC.
Parameter 290 controls whether new users are logged to the USERS file.
RBBS-PC normally logs new users in the users file and recognizes them as
having previously logged on should they call back. If the SYSOP wants new
users not to be logged to the users file specify "NO" to parameter 290.
Parameter 291 allows the SYSOP to permit RBBS-PC to continue operating
should the users file run out of room for new users. Until the SYSOP
rebuilds the users file or expands it, there are then two options:
1. do not let the new user on, or
2. let the new user on but do not try to add him to the user file.
Saying "YES" to parameter 291 enable new users to be allowed on when there
is no room rather than being told there is no room and then disconnected.
RBBS-PC CPC17-2A Page 140
11.16 Use of the Library Sub-System
-----------------------------------
Parameter 301 allows the SYSOP to designate/activate the Library-Subsystem.
The default for this parameter is "<none>". This deactivates the function
in its entirety. To activate the Library-Subsystem select this parameter
and specify the drive that contains your Library Disks. Note: This drive
MUST be a separate drive and not the same drive as any other drive in use
by RBBS-PC. If RBBS-PC is going to be run on a single hard disk and the
Library-Subsystem activated, PC-DOS 3.1 or greater and the SUBST command
must be used to allocate the library disks to a pseudo drive different from
the other drive in use by RBBS-PC.
Parameter 302 is used to select the drive\path where RBBS-PC should look
for the upper level file directory (CDR.CDR is the default name). This
should be the same drive selected in parameter 220.
Parameter 303 allows the extension to be used to identify the Library upper
level directory to be specified. (CDR is the default).
Parameter 304 is used to identify the drive\directory the Library subsystem
should use for creating archive files for transmission. Since the input to
the archive function would be one 360k floppy disk worth of data the space
requirements will be less than 360k. A RAM disk for this use should be
considered. In every case the fastest disk drive available should be
specified in this parameter.
Parameter 305 is used to specify the highest disk number available in the
Library. This value is used in editing the user request for access to the
Library.
Parameter 306 is used to specify the maximum number of upper level
directories that will be found on the Library disk. The PC-SIG CD-ROM is
organized with 10 upper level directories, 1-100, 101-200, 201-300 etc. and
each of these contain 100 directories, DISK001, DISK002 etc.
Parameter 307 is the maximum number of subdirectories that each upper level
directory can contain. (100 in the above example)
Parameter 308 is used to specify the prefix of the lower level directories.
(DISK in the above examples). Since the user enters only the disk number
that is desired, RBBS-PC creates the subdirectory name based on this
parameter and the number entered.
Parameter 309 is used to identify the drive\path\name of the Library Sub-
system menu. MENU6 is the default.
Parameter 310 is a list of the symbols that are available from the Library
Sub-System menu.
Parameter 311 contains the security values related to the symbols listed in
parameter 310.
Parameter 312 is used to identify the drive\path where the archive utility
program can be found. (Be sure that is where it is!)
Parameter 313 is used to identify the archive utility that you wish to use
to do the archiving process on Library disks. When answering the questions
to this parameter you will also be asked what the CREATE parameter is. For
PKARC and ARC the correct response is "A". If using ARCA there is no
CREATE parameter since CREATE is the only function that it can do.
RBBS-PC CPC17-2A Page 141
Therefore just press enter without entering a CREATE command.
RBBS-PC CPC17-2A Page 142
11.17 RBBS-PC's Parameters for Color
------------------------------------
A detailed explanation of the use of colors within RBBS-PC can be found in
section 8.10. Parameter 321 is the string that turns ON highlighting or
emphasizing of characters in text strings displayed to the caller. The
RBBS-PC default is a bright foreground on a red background.
Parameter 322 is the string that turns OFF highlighting or emphasizing of
characters in text strings displayed to the caller. The RBBS-PC default is
amber foreground (normal yellow) and black background.
Parameter 323, parameter 324, parameter 325, parameter 326 and parameter
327 are used in conjunction with one another. Parameter 327 is used to
offset commands a caller actually needs to type in to select an option.
